ScummVM

Hi everybody,

>  * Win32
> 
> Who is building the port this release now that Kirben is gone?

a friend of mine proposed to build the Windows 32 binaries as soon as he solves the last issue he has with cross-compiling under Linux. He would also offer to make the nightly builds. However, some more information would be needed to make the installer.

Regards
Simon Sawatzki
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone

Am 17.05.2011 um 13:22 schrieb Simon Sawatzki:

> Hi everybody,
> 
>> * Win32
>> 
>> Who is building the port this release now that Kirben is gone?
> 
> a friend of mine proposed to build the Windows 32 binaries as soon as he solves the last issue he has with cross-compiling under Linux. He would also offer to make the nightly builds. However, some more information would be needed to make the installer.

That's nice... But... Shouldn't we do a proper search for a Win32 maintainer? If we need one? A fact that seems evident by now, but so far still has not been confirmed by anybody (e.g. Eugene) who has first hand knowledge?


Bye,
Max

> Hi everybody,
> 
> >  * Win32
> > 
> > Who is building the port this release now that Kirben is gone?
> 
> a friend of mine proposed to build the Windows 32 binaries as soon as he
> solves the last issue he has with cross-compiling under Linux.


Well I don't really mind that. Some prebuilt mingw toolchains on Linux I've 
used had libstdc++ etc. dynmically linked by default, it should be taken care 
that this does not happen.

In fact I have a working MinGW toolchain (on a Windows installation) myself, 
my problem was that I am not sure how to create the installer using InnoSetup, 
which is what we will still use this release.

> He would also offer to make the nightly builds. However, some more 
information would be needed to make the installer.
> 

I am not sure about nightly builds, the buildbot ones should be fine, right? In 
fact I always thought we wanted to let buildbot automatically create nightly 
Win32 builds using NSIS as installer. But nobody worked on setting up buildbot 
for that AFAIK. Littleboy might know more about that, so Littleboy any news on 
this?

Anyway if your friend wants to provide nightly builds using an installer in 
the mean time, we could add a link to that from our downloads page for now. 
Though of course currently only branch-1-3-0 builds should be linked there,  
thus NSIS can't be used for now, since we decided 1.3.0 should only use  
InnoSetup.

You should ask him to drop a mail himself about this, since we want 
to have direct contact with people providing "official" builds.

// Johannes

On 17 May 2011 14:37, Max Horn <max@...> wrote:
>
> Am 17.05.2011 um 13:22 schrieb Simon Sawatzki:
>
>> Hi everybody,
>>
>>> * Win32
>>>
>>> Who is building the port this release now that Kirben is gone?
>>
>> a friend of mine proposed to build the Windows 32 binaries as soon as he solves the last issue he has with cross-compiling under Linux. He would also offer to make the nightly builds. However, some more information would be needed to make the installer.
>
> That's nice... But... Shouldn't we do a proper search for a Win32 maintainer? If we need one? A fact that seems evident by now, but so far still has not been confirmed by anybody (e.g. Eugene) who has first hand knowledge?
Yes, I am confirming, that Kirben decided to leave the project and we
need a Win32 maintainer now.

He also requested to have him enlisted in the credits as retired project member.


Eugene

> Am 17.05.2011 um 13:22 schrieb Simon Sawatzki:
> > Hi everybody,
> > 
> >> * Win32
> >> 
> >> Who is building the port this release now that Kirben is gone?
> > 
> > a friend of mine proposed to build the Windows 32 binaries as soon as he
> > solves the last issue he has with cross-compiling under Linux. He would
> > also offer to make the nightly builds. However, some more information
> > would be needed to make the installer.
> 
> That's nice... But... Shouldn't we do a proper search for a Win32
> maintainer? If we need one? A fact that seems evident by now, but so far
> still has not been confirmed by anybody (e.g. Eugene) who has first hand
> knowledge?
> 

We should. I was only takling about this release here, since I think the 
search for a new maintainer is probably a bit more time consuming than we have 
left till we actually need the release builds being done.

In general when looking for a new Win32 maintainer IMHO a criteria for a 
possible maintainer would be that he is using Windows on a daily base and does 
not cross-compile from whatever system he uses instead.

// Johannes

On Tue, May 17, 2011 at 02:11:53PM +0200, Johannes Schickel wrote:
> > Am 17.05.2011 um 13:22 schrieb Simon Sawatzki:
> > > Hi everybody,
> > > 
> > >> * Win32
> > >> 
> > >> Who is building the port this release now that Kirben is gone?
> > > 
> > > a friend of mine proposed to build the Windows 32 binaries as soon as he
> > > solves the last issue he has with cross-compiling under Linux. He would
> > > also offer to make the nightly builds. However, some more information
> > > would be needed to make the installer.
> > 
> > That's nice... But... Shouldn't we do a proper search for a Win32
> > maintainer? If we need one? A fact that seems evident by now, but so far
> > still has not been confirmed by anybody (e.g. Eugene) who has first hand
> > knowledge?
> > 
> 
> We should. I was only takling about this release here, since I think the
> search for a new maintainer is probably a bit more time consuming than we
> have left till we actually need the release builds being done.

Nothing personal against anyone, and I appreciate the offer for binaries, but
also for this release I think we should aim for someone we know and trust
already for something as high-profile as Windows binaries.

-Willem Jan

I could take up this task. However, I am away for work this week, so I
can start working on this from next week, if needed.

Regards
Filippos

On Tuesday, May 17, 2011, Willem Jan Palenstijn <wjp@...> wrote:
> On Tue, May 17, 2011 at 02:11:53PM +0200, Johannes Schickel wrote:
>> > Am 17.05.2011 um 13:22 schrieb Simon Sawatzki:
>> > > Hi everybody,
>> > >
>> > >> * Win32
>> > >>
>> > >> Who is building the port this release now that Kirben is gone?
>> > >
>> > > a friend of mine proposed to build the Windows 32 binaries as soon as he
>> > > solves the last issue he has with cross-compiling under Linux. He would
>> > > also offer to make the nightly builds. However, some more information
>> > > would be needed to make the installer.
>> >
>> > That's nice... But... Shouldn't we do a proper search for a Win32
>> > maintainer? If we need one? A fact that seems evident by now, but so far
>> > still has not been confirmed by anybody (e.g. Eugene) who has first hand
>> > knowledge?
>> >
>>
>> We should. I was only takling about this release here, since I think the
>> search for a new maintainer is probably a bit more time consuming than we
>> have left till we actually need the release builds being done.
>
> Nothing personal against anyone, and I appreciate the offer for binaries, but
> also for this release I think we should aim for someone we know and trust
> already for something as high-profile as Windows binaries.
>
> -Willem Jan
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>

-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde

Hi again,

I don't understand what's wrong with cross-compiling and having it done by someone new. Are you afraid of new team members who might eventually be involved in decisions?

I think it would be nice to have a daily/nightly build again for Win32. The problem with buildbot is that the binaries are very large - 80 MB per file is quite much if you have a traffic limit like I do have with my internet connection. Thus the binaries should be stripped with "strip scummvm.exe". My friend is already capable of doing it with his cross-compiled bundle.
But maybe someone could set up the buildbot to do the stripping itself and then link to the build on the download page? Though we would still have the installer missing this way.

If Filippos is doing the offcial release compiling this time, then fine by me.
I just think that the nightly build should not die because of bureaucratics and long argumentation for and against it. After all, how should someone gain your trust if you don't give him the chance to gain your trust? (This logic sounds rather women-like to me. :) )

Kind regards
Simon
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Am 17.05.2011 um 15:34 schrieb Simon Sawatzki:

> Hi again,
> 
> I don't understand what's wrong with cross-compiling and having it done by someone new. Are you afraid of new team members who might eventually be involved in decisions?

No, not at all. But the Windows port is going to be downloaded by thousands of people. All these people are putting a lot of trust into us. Hence, it seems unwise to let it be made by a person we do not yet know and hence obviously cannot yet fully trust. It's as simple as that.  Nothing personal. 

Establishing trust takes some time, which we don't have until 1.3.0 -- but before the next release, there is plenty of time to get to now new people, and we'll be happy to do it.


> I think it would be nice to have a daily/nightly build again for Win32.

We do have those, as you point out yourself, on buildbot. Certainly not in a perfect form right now, though, but this is being worked on.


> The problem with buildbot is that the binaries are very large - 80 MB per file is quite much if you have a traffic limit like I do have with my internet connection.

Not sure were you got that number from. The latest win32 buildbot binary is 31 MB, the win64 one 64 MB. 


> Thus the binaries should be stripped with "strip scummvm.exe".

On other systems, we explicitly do *not* want to strip the binary in order to not loose the ability to get a backtrace in case ScummVM crashes (e.g. on Mac OS X, if an app crashes, the system will, if configured accordingly automatically pop up a window that allows you get a crash report, including a backtrace, that can then be mailed to the developer).

If there is no reasonable way under windows to get to such a backtrace, then (assuming I forgot nothing else) we should indeed strip the daily builds for Windows.

> My friend is already capable of doing it with his cross-compiled bundle.
> But maybe someone could set up the buildbot to do the stripping itself and then link to the build on the download page?

Sure, that would be trivial to arrange. If somebody confirms that we can't make good of the debug symbols in the Windows builds, I can arrange that at any time.

> Though we would still have the installer missing this way.

Yeah, which is why this should be setup on buildbot ASAP. Here, too, I am happy to help with.

> 
> If Filippos is doing the offcial release compiling this time, then fine by me.
> I just think that the nightly build should not die because of bureaucratics and long argumentation for and against it.

To the contrary, since one of the main reasons for the arguments is gone, finally we are free to setup a reproducible automated daily build that can be understood, verified, modified, tweaked, improved, tested, etc. by multiple team members. It's been forced upon us to do this sooner than desired, and in a way that nobody is really happy about. But IMHO it's good that at least we can now move forward, instead of stupid bickering over a no-brainer improvement.

Of course that's just *my* opinion, and I am certainly biased.


> After all, how should someone gain your trust if you don't give him the chance to gain your trust? (This logic sounds rather women-like to me. :) )

As I mentioned, we'll be happy to evolve a trust relationship, but obviously that needs time. You wouldn't hand your bank account and pin over to somebody you never met before just because he's a friend's friend, would you?



Cheers,
Max

> I don't understand what's wrong with cross-compiling and having it done by
> someone new. 

For merly providing builds it might be fine that it is cross-compiled, in fact 
we even do that ourselves with buildbot, BUT when we talk about a maintainer 
for a *desktop* platform like Windows, it seems strange why he/she should 
cross-compile it, when he's using Windows anyway. In fact I only got the 
feeling your friend is rather using Linux, when you started to talk about him 
cross-compiling.

And just to be clear: The Windows maintainer should use Windows on a daily 
base, he should be familiar with the Windows API and user standards etc. He 
should have a possibility to test his builds of ScummVM on Windows 2k/XP and 
Vista/7. All that helps with a stable and usable Windows port. 

Furthermore our Windows maintainer should probably be able to handle both 
MinGW and MSVC specific problems, to assure all of our developers using either 
of these can work just fine without needing to worry about touching backend 
parts etc. And of course we should have a fast way of contacting him in case 
anything goes wrong. I think there is no need to talk about the fact that he 
should try to keep up on changes on a daily base, since it is one of our main 
platforms.

All that is IMHO though.

Anyway I have no personal feelings against your friend, so if he thinks he can 
handle all that, he should just drop a mail and get in contact with us 
himself.

// Johannes

Am 17.05.2011 um 16:20 schrieb Johannes Schickel:

>> I don't understand what's wrong with cross-compiling and having it done by
>> someone new. 
> 
> For merly providing builds it might be fine that it is cross-compiled, in fact 
> we even do that ourselves with buildbot, BUT when we talk about a maintainer 
> for a *desktop* platform like Windows, it seems strange why he/she should 
> cross-compile it, when he's using Windows anyway. In fact I only got the 
> feeling your friend is rather using Linux, when you started to talk about him 
> cross-compiling.
> 
> And just to be clear: The Windows maintainer should use Windows on a daily 
> base, he should be familiar with the Windows API and user standards etc. He 
> should have a possibility to test his builds of ScummVM on Windows 2k/XP and 
> Vista/7. All that helps with a stable and usable Windows port. 
> 
> Furthermore our Windows maintainer should probably be able to handle both 
> MinGW and MSVC specific problems, to assure all of our developers using either 
> of these can work just fine without needing to worry about touching backend 
> parts etc. And of course we should have a fast way of contacting him in case 
> anything goes wrong. I think there is no need to talk about the fact that he 
> should try to keep up on changes on a daily base, since it is one of our main 
> platforms.
> 
> All that is IMHO though.
> 
> Anyway I have no personal feelings against your friend, so if he thinks he can 
> handle all that, he should just drop a mail and get in contact with us 
> himself.


+1 to everything Johannes wrote.


Bye,
Max

Hi!

I can also do Windows builds (both mingw & MSVC) for 1.3.x if needed.

Going forward, the NSIS installer script should be ready to be integrated
into buildbot for daily win32 builds (I recently fixed some remaining
problems with out of tree builds).
The tools will also need an installer (working on it right now).

Julien

> -----Original Message-----
> From: Max Horn [mailto:max@...]
> Sent: Tuesday, May 17, 2011 10:29 AM
> Cc: scummvm-devel@...
> Subject: Re: [Scummvm-devel] Release 1.3.0 status - 2011-05-16
> 
> 
> Am 17.05.2011 um 16:20 schrieb Johannes Schickel:
> 
> >> I don't understand what's wrong with cross-compiling and having it done
> by
> >> someone new.
> >
> > For merly providing builds it might be fine that it is cross-compiled,
in fact
> > we even do that ourselves with buildbot, BUT when we talk about a
> maintainer
> > for a *desktop* platform like Windows, it seems strange why he/she
> should
> > cross-compile it, when he's using Windows anyway. In fact I only got the
> > feeling your friend is rather using Linux, when you started to talk
about him
> > cross-compiling.
> >
> > And just to be clear: The Windows maintainer should use Windows on a
> daily
> > base, he should be familiar with the Windows API and user standards etc.
> He
> > should have a possibility to test his builds of ScummVM on Windows 2k/XP
> and
> > Vista/7. All that helps with a stable and usable Windows port.
> >
> > Furthermore our Windows maintainer should probably be able to handle
> both
> > MinGW and MSVC specific problems, to assure all of our developers using
> either
> > of these can work just fine without needing to worry about touching
> backend
> > parts etc. And of course we should have a fast way of contacting him in
> case
> > anything goes wrong. I think there is no need to talk about the fact
that he
> > should try to keep up on changes on a daily base, since it is one of our
main
> > platforms.
> >
> > All that is IMHO though.
> >
> > Anyway I have no personal feelings against your friend, so if he thinks
he
> can
> > handle all that, he should just drop a mail and get in contact with us
> > himself.
> 
> 
> +1 to everything Johannes wrote.
> 
> 
> Bye,
> Max
>
----------------------------------------------------------------------------
--
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel

Johannes Schickel <lordhoto@...> writes:

>  * DC
>
> Marcus could you please drop another mail about whether the regression testing 
> you talked about went fine?

I've tested the things I wanted to check specifically, and they still
worked correctly, as far as I could tell.


  // Marcus

> Johannes Schickel <lordhoto@...> writes:
> >  * DC
> > 
> > Marcus could you please drop another mail about whether the regression
> > testing you talked about went fine?
> 
> I've tested the things I wanted to check specifically, and they still
> worked correctly, as far as I could tell.
> 

Thank you for the update. That's nice to hear then :-).

// Johannes

Hi Team,

PS2  port was doing fine last time I checked - there are still couple of 
things I'd like to try (like test "configure"-build, etc.).

I allocated some time in the upcoming week-end to test few more games, 
so we should be "go" ;-)

Thanks,
-max


> Hi,
>
> Eugene proposed that we delay the release by a week, since we still have the 
> AGI release critical bug open and NDS seems to have problems right now too. 
> Since he is currently busy with real-life he asked me to write a mail about 
> this.
>
> So our schedule will now look like:
>
>   May 23rd   -- tagging, release tarballs are uploaded
>   May 27th   -- release
>
> As far as I can tell we have are fine with the following ports:
>
>  * Android
>  * Dingux
>  * GC/Wii
>  * iPhone (at least there had been a few commits recently and I did not read  
> otherwise)
>  * N64
>  * PSP
>  * Symbian
>  * WebOS
>  * WinCE
>
> The following ports could need a status update (or I missed some mails, sorry 
> in that case):
>
>  * GP2X/Wiz /and Caanoo)
>  * Openpandora
>
> They seem to build fine on buildbot right now, but I did not read anything 
> about them otherwise. John could you please explain their status?
>
>  * DC
>
> Marcus could you please drop another mail about whether the regression testing 
> you talked about went fine?
>
>  * PS2
>  * Linuxmoto
>  * Maemo
>  * SamsungTV
>
> I just did not hear anything from these, so please if you are the port 
> maintainer drop a mail about their status.
>
> Last but not least the ports where we know we have still to fix some issues:
>
>  * NDS
>
> According to Neil's email it seems there is still some issues due to increased 
> memory footprint.
>
>  * Win32
>
> Who is building the port this release now that Kirben is gone?
>
>
> Next just a slight update to the bug list from the last status update email:
>
> Fixed since last status update (this only includes bugs from this list!):
>
> 3093310: T7G: App Crashes Attempting To Save
> 3288328: SCI:QFG2 can't buy healing pills
>
> Release critical:
> 3094846: AGI: Misaligned message box in BC, SQ1, SQ2
>
> Nice to get fixed:
> 1847454: DIG: Rat Trap Puzzle Error
> 1947723: SAM: text off screen in german version
> 2721332: DIG: Cursor delays to appear after scene skip
> 3022067: COMI: crash on 1-st scene (Russian version)
> 3174197: FOA: Wrong colors in the Amiga version
> 2951521: SPYFOX 3: Sprite problem
>
> 3084939: WOODRUFF: Possible lockup in the prison tower
> 3084414: WOODRUFF: Annoying scrolling behaviour in windowed mode
> 3083442: WOODRUFF: Can't Get Master's Powers
> 2867675: GOB3: Duplicate main character sprite
>
> 3034704: GK1 Demo: Can't research Malia
>
> 3280674: ScummTools do not compress monster.sou of german fdd-version
>
> 2880939: NIPPON: No Elder
> 2957333: MADE: Screen effects sometimes look wrong/bad
> 2886145: ITE: Jail bug after speaking to Shiala
> 3166235: KYRA: Crash on startup on OS X.
> 3149412: BASS: Invalid Mode when giving shades to travel agent
> 3065376: DRACI: Inventory word are truncated
> 3069981: DRASCULA: no subtitles in scene with "von Braun"
>
> 3116541: AGI FAN Beyond the Titanic 2: Crash on Item Viewing
> 3080415: AGI: KQ4: Intro Text Box glich
> 3080041: AGI Mother Goose: White bar in intro
> 3080030: AGI Mother Goose: No text in speech bubble
> 3074570: AGI LSL1: TAB stops working after restart
> 3032379: SQ2 : Falling Off Log Almost Immediate
> 3018770: AGI: PQ1: Flickering newspaper
>
> 3011646: WAXWORKS: Tomb visitors check in, they don't check out
> 3011639: WAXWORKS: Doors remain open after loading earlier save game
> 3011635: WAXWORKS: Save games don't track completed waxworks
>
>
> // Johannes
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
>
>

Hi all

On 16.5.2011 23:09, Johannes Schickel wrote:
> So our schedule will now look like:
>
>    May 23rd   -- tagging, release tarballs are uploaded

Was this postponed? What is current plan?

>   * Maemo
>
> I just did not hear anything from these, so please if you are the port
> maintainer drop a mail about their status.

Sorry, I did not manage to test a Maemo build from branch-1-3-0 yet. I 
hope to get it done this weekend.

But no need to postpone tagging just because of me IMO. Most people get 
scummvm from Maemo repositories (visible also via 
http://downloads.maemo.org) so there is not a big harm done when Maemo 
binary and source patch is missing from scummvm.org this time. Maemo 
repositories will get both.

Anyway, if you decide to postpone by one week I'll try hard to not to 
miss the deadline this time :-)


Frantisek

Am 24.05.2011 um 12:05 schrieb Frantisek Dufka:

> Hi all
> 
> On 16.5.2011 23:09, Johannes Schickel wrote:
>> So our schedule will now look like:
>> 
>>   May 23rd   -- tagging, release tarballs are uploaded
> 
> Was this postponed? What is current plan?

It seems it has indeed been postponed. An email on the subject by somebody who knows (Eugene?) would be really nice, though...


> 
>>  * Maemo
>> 
>> I just did not hear anything from these, so please if you are the port
>> maintainer drop a mail about their status.
> 
> Sorry, I did not manage to test a Maemo build from branch-1-3-0 yet. I 
> hope to get it done this weekend.

Yes, please! Our git repository *still* contains that patch for 1.1.0, i.e. not even for 1.2.0. This time, please make sure to make your changes both on master and the release branch.

> 
> But no need to postpone tagging just because of me IMO. Most people get 
> scummvm from Maemo repositories (visible also via 
> http://downloads.maemo.org) so there is not a big harm done when Maemo 
> binary and source patch is missing from scummvm.org this time. Maemo 
> repositories will get both.

Yes, there *is* great harm done, because that would violate the GPL once again. The full source code for the binary made available on http://downloads.maemo.org must be made available to all users; and more than that, valid instructions on how to obtain that source code must be included. If the source code is not in our repository, then you must provide the source code in an alternate location, and modify your distribution accordingly, making the relevant code available (and by the GPL, for at least three years, though I guess once the code is in the official repository, that would also work).


> 
> Anyway, if you decide to postpone by one week I'll try hard to not to 
> miss the deadline this time :-)
> 
> 
> Frantisek
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery, 
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now. 
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>

On 24.5.2011 12:22, Max Horn wrote:
> Yes, there *is* great harm done, because that would violate the GPL once again.

Maemo uses normal debian repositories and uses autobuilder so there is a 
full source for published binary which is used to build the binaries

binaries
http://repository.maemo.org/extras/pool/fremantle/free/s/scummvm/
http://repository.maemo.org/extras/pool/diablo/free/s/scummvm/

sources
http://repository.maemo.org/extras/pool/fremantle/free/source/s/scummvm/
http://repository.maemo.org/extras/pool/diablo/free/source/s/scummvm/

or check the autobuilder page with all links
http://maemo.org/packages/view/scummvm/

And BTW the sources there are not 1:1 copies of published scummvm.org 
sources. There are slight differences in build scripts for specific OS 
versions (compiler flags, debian package dependencies, ...) to satisfy 
Maemo autobuilder for specific OS version.

The patch commited to scummvm.org is used (as is, according to procedure 
described in scummvm README) to build 'universal' binary published at 
scummvm.org. This binary is statically linked to some libraries so it 
works across all maemo devices and is thus a bit suboptimal due to 
bigger size and lowest common compiler flags. Preferred source of 
scummvm package for Maemo devices is Maemo repository relevant to 
specific Maemo version (just like with Ubuntu/Debian/Redhat or other 
distributions).

I definitely think having Maemo build on scummvm.org pages is great. I 
just said there is no _big_ harm done this time if you want to go ahead 
with tagging and do not wait for me. I really don't want to delay the 
release just because I missed the deadline (which is my fault).

Frantisek

Am 24.05.2011 um 12:54 schrieb Frantisek Dufka:

> On 24.5.2011 12:22, Max Horn wrote:
>> Yes, there *is* great harm done, because that would violate the GPL once again.
> 
> Maemo uses normal debian repositories and uses autobuilder so there is a 
> full source for published binary which is used to build the binaries
> 
> binaries
> http://repository.maemo.org/extras/pool/fremantle/free/s/scummvm/
> http://repository.maemo.org/extras/pool/diablo/free/s/scummvm/
> 
> sources
> http://repository.maemo.org/extras/pool/fremantle/free/source/s/scummvm/
> http://repository.maemo.org/extras/pool/diablo/free/source/s/scummvm/
> 
> or check the autobuilder page with all links
> http://maemo.org/packages/view/scummvm/

That's excellent news. Please add a backends/platform/maemo/README file that explains all this (you could just copy your email). That would avoid confusion by me and potential users in the future :)

Cheers,
Max

Am 24.05.2011 um 12:54 schrieb Frantisek Dufka:

> On 24.5.2011 12:22, Max Horn wrote:
>> Yes, there *is* great harm done, because that would violate the GPL once again.
> 
> Maemo uses normal debian repositories and uses autobuilder so there is a 
> full source for published binary which is used to build the binaries
> 
> binaries
> http://repository.maemo.org/extras/pool/fremantle/free/s/scummvm/
> http://repository.maemo.org/extras/pool/diablo/free/s/scummvm/
> 
> sources
> http://repository.maemo.org/extras/pool/fremantle/free/source/s/scummvm/
> http://repository.maemo.org/extras/pool/diablo/free/source/s/scummvm/
> 
> or check the autobuilder page with all links
> http://maemo.org/packages/view/scummvm/


PS: http://maemo.org/packages/view/scummvm/ still uses our old icon. Any chance you could update that to the new one? As found here: <http://scummvm.svn.sourceforge.net/viewvc/scummvm/media/trunk/>


Bye,
Max

On Tue, May 24, 2011 at 01:02:43PM +0200, Max Horn wrote:
> 
> Am 24.05.2011 um 12:54 schrieb Frantisek Dufka:
> 
> > On 24.5.2011 12:22, Max Horn wrote:
> >> Yes, there *is* great harm done, because that would violate the GPL once again.
> > 
> > Maemo uses normal debian repositories and uses autobuilder so there is a 
> > full source for published binary which is used to build the binaries
> > 
> > binaries
> > http://repository.maemo.org/extras/pool/fremantle/free/s/scummvm/
> > http://repository.maemo.org/extras/pool/diablo/free/s/scummvm/
> > 
> > sources
> > http://repository.maemo.org/extras/pool/fremantle/free/source/s/scummvm/
> > http://repository.maemo.org/extras/pool/diablo/free/source/s/scummvm/
> > 
> > or check the autobuilder page with all links
> > http://maemo.org/packages/view/scummvm/
> 
> That's excellent news. Please add a backends/platform/maemo/README file that explains all this (you could just copy your email). That would avoid confusion by me and potential users in the future :)

Did anything come out of this?
I am trying to build 1.3.0 and also the latest master for Maemo.
-- 
Tarek

Am 19.06.2011 um 08:48 schrieb Tarek Soliman:

> On Tue, May 24, 2011 at 01:02:43PM +0200, Max Horn wrote:
>> 
>> Am 24.05.2011 um 12:54 schrieb Frantisek Dufka:
>> 
>>> On 24.5.2011 12:22, Max Horn wrote:
>>>> Yes, there *is* great harm done, because that would violate the GPL once again.
>>> 
>>> Maemo uses normal debian repositories and uses autobuilder so there is a 
>>> full source for published binary which is used to build the binaries
>>> 
>>> binaries
>>> http://repository.maemo.org/extras/pool/fremantle/free/s/scummvm/
>>> http://repository.maemo.org/extras/pool/diablo/free/s/scummvm/
>>> 
>>> sources
>>> http://repository.maemo.org/extras/pool/fremantle/free/source/s/scummvm/
>>> http://repository.maemo.org/extras/pool/diablo/free/source/s/scummvm/
>>> 
>>> or check the autobuilder page with all links
>>> http://maemo.org/packages/view/scummvm/
>> 
>> That's excellent news. Please add a backends/platform/maemo/README file that explains all this (you could just copy your email). That would avoid confusion by me and potential users in the future :)
> 
> Did anything come out of this?
> I am trying to build 1.3.0 and also the latest master for Maemo.

Everything that came out of this (= nothing) is on full public record.


Since this state has been going on for years now, I propose that we delete the maemo port files from our repository now, and revoke its status as an official port. 


Bye,
Max

I find the current status of the Maemo port to be very confusing.

>From what I see, we never got any proper build scripts / instructions for
this port, and
we place links to downloads.maemo.org. Plus, there doesn't seem to be any
source
code. If this is indeed the situation, I too feel that we should remove the
Maemo
port from our list of official ports, as it violates the GPL, and the people
who build this
clearly don't care to support this port properly.

Regards
Filippos

On Mon, Jun 20, 2011 at 2:07 AM, Max Horn <max@...> wrote:

>
> Am 19.06.2011 um 08:48 schrieb Tarek Soliman:
>
> > On Tue, May 24, 2011 at 01:02:43PM +0200, Max Horn wrote:
> >>
> >> Am 24.05.2011 um 12:54 schrieb Frantisek Dufka:
> >>
> >>> On 24.5.2011 12:22, Max Horn wrote:
> >>>> Yes, there *is* great harm done, because that would violate the GPL
> once again.
> >>>
> >>> Maemo uses normal debian repositories and uses autobuilder so there is
> a
> >>> full source for published binary which is used to build the binaries
> >>>
> >>> binaries
> >>> http://repository.maemo.org/extras/pool/fremantle/free/s/scummvm/
> >>> http://repository.maemo.org/extras/pool/diablo/free/s/scummvm/
> >>>
> >>> sources
> >>>
> http://repository.maemo.org/extras/pool/fremantle/free/source/s/scummvm/
> >>> http://repository.maemo.org/extras/pool/diablo/free/source/s/scummvm/
> >>>
> >>> or check the autobuilder page with all links
> >>> http://maemo.org/packages/view/scummvm/
> >>
> >> That's excellent news. Please add a backends/platform/maemo/README file
> that explains all this (you could just copy your email). That would avoid
> confusion by me and potential users in the future :)
> >
> > Did anything come out of this?
> > I am trying to build 1.3.0 and also the latest master for Maemo.
>
> Everything that came out of this (= nothing) is on full public record.
>
>
> Since this state has been going on for years now, I propose that we delete
> the maemo port files from our repository now, and revoke its status as an
> official port.
>
>
> Bye,
> Max
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>



-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde

On Mon, Jun 20, 2011 at 04:15:28AM +0300, Filippos Karapetis wrote:
> I find the current status of the Maemo port to be very confusing.
> 
> >From what I see, we never got any proper build scripts / instructions for
> this port, and
> we place links to downloads.maemo.org. Plus, there doesn't seem to be any
> source
> code. If this is indeed the situation, I too feel that we should remove the
> Maemo
> port from our list of official ports, as it violates the GPL, and the people
> who build this
> clearly don't care to support this port properly.

I found source on maemo.org and have put it on https://github.com/tsoliman/scummvm/tree/maemo
This is a branch off of the v1.2.0 tag.

I will give porting it to 1.3.0 a shot later.
I just wanted to make sure no one else (who actually knew what they were doing) was doing the same.
-- 
Tarek

On 20.6.2011 3:15, Filippos Karapetis wrote:
>  From what I see, we never got any proper build scripts / instructions
> for this port

False, see the README

Also Maemo repositories has full automatically buildable source.

>, and
> we place links to downloads.maemo.org <http://downloads.maemo.org>.

There was also .deb file for all official releases except 1.3.0 (as for 
1.3.0 I missed the deadline). Maemo repositories are however preferred 
as it is for any other linux distribution.

> Plus, there doesn't seem to be any source
> code.

Every binary released on scummvm.org was built from official scummvm 
source 'as is' according to instructions in scummvm README

> If this is indeed the situation

No it is not.

> I too feel that we should remove
> the Maemo
> port from our list of official ports

It is of course up to scummvm.org maintainters.

, as it violates the GPL, and the
> people who build this
> clearly don't care to support this port properly.

Reading list archives or http://wiki.scummvm.org/index.php/Maemo would 
be better than all this guesswork and accusations. Also CCing me would 
be nice too, it is really not hard to figure out who are 'the people who 
build this'.

Also anyone is (and always was) welcome to join and 'suport this port 
properly' :-)

Frantisek

On 20.6.2011 5:46, Tarek Soliman wrote:

> I found source on maemo.org and have put it on https://github.com/tsoliman/scummvm/tree/maemo
> This is a branch off of the v1.2.0 tag.

Latest patch is part of official 1.2.1 source. This is the hard rule as 
I understand it - released binary must be built from released source. It 
was always like this for any released official scummvm.org Maemo build.

For building see bottom of 
https://github.com/scummvm/scummvm/blob/master/README

Binary published at scummvm.org is built with maemo 2.2 SDK so it runs 
on all devices and all Maemo OS  versions. Because of that, it also has 
some dependencies (libmad, vorbis, flac) linked statically.

> I just wanted to make sure no one else (who actually knew what they were doing) was doing the same.

As I missed 1.3.0 I was planning to catch up with 1.3.1 in the old 
patchy way but any help (or even takeover) is welcome.

The core reason for the patch was that some bits patch directly engine 
sources with maemo specific keymapping changes and that was always 
unacceptable to merge directly. For more reasoning see my previous mails 
in the archive. The situation can be improved a lot (i.e. patch can be 
minimized) I just didn't consider it as a top priority. Also for N900 
device new backend (based on Qt and/or OpenGL ES) would be more suitable 
to allow smooth scaling (most requested feature - scale to full 800x480 
screen) and possibly having some on-screen keyboard/button widget.

Frantisek

>> If this is indeed the situation
>
> No it is not.

Um, excuse me, I understand your anger, but the only source code we
got for this port is in form of a patch against 1.1.0 in
/backends/platform/maemo. And the situation is that we need your
source code changes in the tree. Giving a link to a tar.gz is with
your changes is not, I'm afraid, the proper way to do this.

It seems that we could automate its build process with buildbot too,
right? What kind of toolchain is required for this port?

> Reading list archives or http://wiki.scummvm.org/index.php/Maemo would be
> better than all this guesswork and accusations. Also CCing me would be nice
> too, it is really not hard to figure out who are 'the people who build
> this'.

You are supposed to be subscribed to scummvm-devel, so why should you be
specifically CCed here?

Regards
Filippos

-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde

On 29.6.2011 10:13, Filippos Karapetis wrote:
> Um, excuse me, I understand your anger

There is no anger.

> got for this port is in form of a patch against 1.1.0 in
> /backends/platform/maemo.

False again. Every release of scummvm source has separate patch 
included. Also every tagged release in svn had this patch too in 
backends/platform/maemo , 1.2.1 is the last one as I missed 1.3.0 deadline

It is only the trunk that has no patch because it makes no sense. It 
would be outdated and broken with any major change done in trunk. How 
often am I supposed to update it?

> It seems that we could automate its build process with buildbot too,
> right? What kind of toolchain is required for this port?

see scratchbox.org, Maemo has no supported cross-compiler in the normal 
sense. It could work in theory but it is not done this way. Maemo 
autobuilder installs whole scratchbox virtual environment (like chroot 
but not exactly chroot, there is some additional magic) from scratch, 
then pulls and install all source dependencies and then builds the 
package and throws everything out.

For example see
https://garage.maemo.org/builder/fremantle/scummvm_1.2.0/armel.root.log.OK.txt 
- log  of scratchbox root fs installation for scummvm build

https://garage.maemo.org/builder/fremantle/scummvm_1.2.0/armel.build.log.OK.txt 
- log of scummvm build itself

>
>> Reading list archives or http://wiki.scummvm.org/index.php/Maemo would be
>> better than all this guesswork and accusations. Also CCing me would be nice
>> too, it is really not hard to figure out who are 'the people who build
>> this'.
>
> You are supposed to be subscribed to scummvm-devel, so why should you be
> specifically CCed here?

Because that would be nice and polite thing to do? Especially when 
starting uninformed flamewar ;-)

BTW, I am subscribed to scummvm-devel. I just don't read it every day. 
For any Maemo related stuff it is better to CC me. I guess it is same 
for any other porter who is not core developer.

Frantisek

On Wed, Jun 29, 2011 at 10:48:48AM +0200, Frantisek Dufka wrote:
> It is only the trunk that has no patch because it makes no sense. It 
> would be outdated and broken with any major change done in trunk. How 
> often am I supposed to update it?

If it is only in the branches, it will get lost, as you've seen. And it's
even worse since trunk has a patch for 1.1.0 -- it is not an unreasonable
assumption that it hasn't been updated since then..

- fuzzie

A general question: why don't you join github, so that all of these
changes can be merged
into our code tree? That way, this port will be like all of the
others, and we can have its source
code in our code tree, like with everything else (and like GPL
specifically requests)/

I've just reviewed the patch we got in the tree (/backends/platform/maemo).

Here are some observations/questions. Note that these are against the
patch we got against 1.1.0, so things might have changed. Your work is
greatly appreciated, though there are some things which strike me as
odd:

- What is wrong with the ScummVM icon, so that there is a specific
hack to replace it (in postinit).
If this is to get the icon to show on the window, you could override
setupIcon() instead (check how it's done for the Windows backend in
/backends/platform/sdl/win32/win32.cpp)
- Is there a reason why this port uses an additional external include
for building? (/usr/share/quilt/quilt.make)
- Why are you changing the paths inside configure?
- What error are you getting with kyra/screen.cpp? Can you use a newer
GCC version?
- In general, I see you put in a special handling for the F4 key in
all of the engines... why? We got a menu which pops up with
Control-F5, so overriding that seems a bit more generic than hacking
an F4 key into all of the engines. Plus, some engine might be using
F4, whereas no engine is using Control-F5.
- I see you did the same with the Up, Down, Enter and F8 keys... again
shouldn't these be remapped in the backend, instead of all of the
engines?
- You did some key remapping in /backends/platform/sdl/events.cpp, so
why are some keys remapped in the engine level and some in the backend
level?
- Why is SDL_syswm.h needed? Any specific functionality you need from
it? Could it be the window name? So that means that ScummVM is running
as a window in this platform? If this is the case, you could override
setWindowCaption() instead (e.g. check /platform/sdl/sdl.cpp).
- Why is the SCUMM restart dialog disabled?

Regards
Filippos

On Wed, Jun 29, 2011 at 11:13 AM, Filippos Karapetis <bluegr@...> wrote:
>>> If this is indeed the situation
>>
>> No it is not.
>
> Um, excuse me, I understand your anger, but the only source code we
> got for this port is in form of a patch against 1.1.0 in
> /backends/platform/maemo. And the situation is that we need your
> source code changes in the tree. Giving a link to a tar.gz is with
> your changes is not, I'm afraid, the proper way to do this.
>
> It seems that we could automate its build process with buildbot too,
> right? What kind of toolchain is required for this port?
>
>> Reading list archives or http://wiki.scummvm.org/index.php/Maemo would be
>> better than all this guesswork and accusations. Also CCing me would be nice
>> too, it is really not hard to figure out who are 'the people who build
>> this'.
>
> You are supposed to be subscribed to scummvm-devel, so why should you be
> specifically CCed here?
>
> Regards
> Filippos
>
> --
> "Experience is the name every one gives to their mistakes" - Oscar Wilde
>



-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde

On Wed, Jun 29, 2011 at 11:48 AM, Frantisek Dufka <dufkaf@...> wrote:
> On 29.6.2011 10:13, Filippos Karapetis wrote:
>>
>> Um, excuse me, I understand your anger
>
> There is no anger.

Good :)

>> got for this port is in form of a patch against 1.1.0 in
>> /backends/platform/maemo.
>
> False again. Every release of scummvm source has separate patch included.
> Also every tagged release in svn had this patch too in
> backends/platform/maemo , 1.2.1 is the last one as I missed 1.3.0 deadline

No, this is not the way to do it. We need your changes in our trunk,
plain and simple

> It is only the trunk that has no patch because it makes no sense. It would
> be outdated and broken with any major change done in trunk. How often am I
> supposed to update it?

Preferably on every stable release, i.e. every 6 months, like with all
the other ports (but if you want to update it sooner than that, you're
free to do so, of course :P )

>> It seems that we could automate its build process with buildbot too,
>> right? What kind of toolchain is required for this port?
>
> see scratchbox.org, Maemo has no supported cross-compiler in the normal
> sense. It could work in theory but it is not done this way. Maemo
> autobuilder installs whole scratchbox virtual environment (like chroot but
> not exactly chroot, there is some additional magic) from scratch, then pulls
> and install all source dependencies and then builds the package and throws
> everything out.

Right, OK, thanks for clearing this out!

>> You are supposed to be subscribed to scummvm-devel, so why should you be
>> specifically CCed here?
>
> Because that would be nice and polite thing to do? Especially when starting
> uninformed flamewar ;-)

Er, it's not a flamewar, or an uninformed flamewar. You specifically
don't add your changes to our tree, which is where this whole debate
started from. If you are part of the team, and if you want your port
to be considered official, you really should subscribe and watch the
scummvm-devel mailing list.

> BTW, I am subscribed to scummvm-devel. I just don't read it every day. For
> any Maemo related stuff it is better to CC me. I guess it is same for any
> other porter who is not core developer.

Not quite, again, you are supposed to read the mailing list, we really
don't know what change affects your port and what doesn't. We can't
guess when to contact each and every developer, which is why there is
a mailing list for that, which developers and porters should read
themselves (e.g. there have been specific messages to all porters to
the mailing list in the past, you included).

Regards
Filippos

-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde

> > BTW, I am subscribed to scummvm-devel. I just don't read it every day.
> > For any Maemo related stuff it is better to CC me. I guess it is same
> > for any other porter who is not core developer.
> 
> Not quite, again, you are supposed to read the mailing list, we really
> don't know what change affects your port and what doesn't. We can't
> guess when to contact each and every developer, which is why there is
> a mailing list for that, which developers and porters should read
> themselves (e.g. there have been specific messages to all porters to
> the mailing list in the past, you included).
> 

While that is generally true, in this case it was obvious that it affects his 
port. Furthermore in the past if we knew that it affects a special 
port/engine/whatever we always tried to CC the maintainer/developer. IMHO we 
should continue to do this, since it makes sure nothing is missed.

// Johannes

On 29 June 2011 12:07, Filippos Karapetis <bluegr@...> wrote:
> Er, it's not a flamewar, or an uninformed flamewar. You specifically
> don't add your changes to our tree, which is where this whole debate
> started from. If you are part of the team, and if you want your port
> to be considered official, you really should subscribe and watch the
> scummvm-devel mailing list.
As it was already pointed out by Frantisek, he _does_ add his patch to
every branch shortly before release, for all releases which included
Maemo port.

All your notes to the patch are valid, and I've mentioned the
keymapping in my early email. It is just happened that the porter
never had enough time to get rid of those hacks, and I did not allow
them to be committed in the mainline, hence this problem with patch.

It is problematic to maintain the patch against ever-changing trunk,
thus Frantisek was syncing it only for release branches. Instead of
asking to keep the patch always applicable it would be better to sync
into implementing it properly, e.g. continue with hack implemented by
WinCE or Symbian port, where keymapping is hardcoded in the backend,
or do it in a proper way and invest some time in our unfinished
KeyMapper code.


Eugene

On 29 June 2011 17:08, Johannes Schickel <lordhoto@...> wrote:
>> Not quite, again, you are supposed to read the mailing list, we really
>> don't know what change affects your port and what doesn't. We can't
>> guess when to contact each and every developer, which is why there is
>> a mailing list for that, which developers and porters should read
>> themselves (e.g. there have been specific messages to all porters to
>> the mailing list in the past, you included).
>>
>
> While that is generally true, in this case it was obvious that it affects his
> port. Furthermore in the past if we knew that it affects a special
> port/engine/whatever we always tried to CC the maintainer/developer. IMHO we
> should continue to do this, since it makes sure nothing is missed.
Absolutely, The reality shows that many of our porters do not read
-devel. Thus CC'ing the maintainer is always the Good Thing(TM).


Eugene

On 29.6.2011 11:01, Filippos Karapetis wrote:
> A general question: why don't you join github, so that all of these
> changes can be merged
> into our code tree?

Lack of time. I'd like to. Already registered to github but need to 
learn git more. That's one reason why I missed 1.3.0 deadline - 
switching from svn to git way of doing stuff.

> That way, this port will be like all of the
> others

Still learning but I guess with git I can maintain my own scummvm 
branch/fork more visibly and somehow merge stuff or generate the patch 
more easily.

> I've just reviewed the patch we got in the tree (/backends/platform/maemo).

latest is
https://github.com/scummvm/scummvm/tree/v1.2.1/backends/platform/maemo

>
> - What is wrong with the ScummVM icon, so that there is a specific
> hack to replace it (in postinit).

Maemo OS 2006 for 770 needs low resolution xpm icon, OS2007 and up needs 
high resolution png but the low resolution one overrrides the high 
resolution one and looks ugly when present. So for OS > 2006 I need to 
remove the xpm one at package install time, see
https://github.com/scummvm/scummvm/blob/v1.2.1/backends/platform/maemo/scummvm-1.2-maemo.patch#L325

> If this is to get the icon to show on the window

Icon is for system application 'start' menu.

> - Is there a reason why this port uses an additional external include
> for building? (/usr/share/quilt/quilt.make)

This is for quilt tool, it is one of build dependencies. Quilt was used 
for applying some specific patches at build time when uploading same 
source archive to Maemo autobuilder for different targets (OS2008 vs 
Maemo 5). It didn't solve everything so right now all patches managed by 
quilt are integrated and quilt currently does nothing and the dependency 
can be removed. It is harmless though.

> - Why are you changing the paths inside configure?

Explained few times, last time to Max earlier in this thread. See
Subject: Re: [Scummvm-devel] Release 1.3.0 status -- 2010-04-24
Date: Tue, 24 May 2011 14:20:49 +0200
CC: ScummVM devel <scummvm-devel@...>

There is more about Maemo port status in that thread so might be worth 
reading. Max had some very good suggestions so there is no need to 
reinvent the wheel.

In general when I was more active in Maemo and ScummVM there was no 
other practical way to do Maemo port than patching sdl backend and 
engines directly. Now the SDL backend is modularized and there is 
keymapper in some form so now there are better ways. But my spare coding 
time became recently very limited and also Maemo is less and less 
relevant (some would say dead) so I am no longer up to speed with recent 
scummvm changes.

> - What error are you getting with kyra/screen.cpp? Can you use a newer
> GCC version?

https://github.com/scummvm/scummvm/blob/v1.2.1/backends/platform/maemo/scummvm-1.2-maemo.patch#L449
internal compiler error with -O2 or -Os, no newer compiler for 770

> - In general, I see you put in a special handling for the F4 key in
> all of the engines... why? We got a menu which pops up with
> Control-F5, so overriding that seems a bit more generic than hacking
> an F4 key into all of the engines. Plus, some engine might be using
> F4, whereas no engine is using Control-F5.

Nokia 770 and N800 has no keyboard. Only directional keypad and few keys 
mapped to F4-F8 and F5 is eaten by system (f5 = home key = device goes 
to home screen or pops up task manager menu, no way to block it) So I 
need to map f5 out and map most stuff to f4,f6,f7,f8 and keypad, see
http://wiki.scummvm.org/index.php/Maemo#Device_specific_keybindings

> - You did some key remapping in /backends/platform/sdl/events.cpp, so
> why are some keys remapped in the engine level and some in the backend
> level?

The mapping in events.cpp is newer way and I could perhaps rewrite some 
of older engine patches to this way (and I already did some over time) 
but not all. Some of them are engine state specific (i.e. maemo mapping 
is changed in engine only for some code paths, not all) so not 
everything can live in events.cpp

> - Why is SDL_syswm.h needed?

Needed for some Maemo5 (N900) hacks/workarounds, see 
https://github.com/scummvm/scummvm/blob/v1.2.1/backends/platform/maemo/scummvm-1.2-maemo.patch#L843

> - Why is the SCUMM restart dialog disabled?

In general this is because for devices with no keyboard and limited keys 
there is either no way to invoke it or it interferes with available key 
needed for other action.

In this case it is F8 which maemo uses for 'zoom -' key and is mapped to 
something else.


Regards,
Frantisek

BTW, there is no need to forward all emails to me, I am subscribed to 
scummvm-devel, it was only good to CC: me first time when replying to a 
month old thread.

On Wed, Jun 29, 2011 at 05:43:08PM +0300, Eugene Sandulenko wrote:
> it would be better to sync
> into implementing it properly, e.g. continue with hack implemented by
> WinCE or Symbian port, where keymapping is hardcoded in the backend,
> or do it in a proper way and invest some time in our unfinished
> KeyMapper code.

I am not sure what the current status of the keymapper is.

I have started doing this in https://github.com/tsoliman/scummvm/tree/maemo-cleanup.
Specifically: https://github.com/tsoliman/scummvm/commit/bafe2bcf60d63e14bfea7e66da12940159ca556c

I've seen that the SamsungTV backend implements SamsungTVSdlEventSource::remapKey(SDL_Event &ev, Common::Event &event)
Is that the unfinished keymapper code?
I can't get this to work; that code never gets hit.

I am going to have to resort to the WinCE "hack" which I am assuming is to override SdlEventSource::pollEvent(Common::Event &event)
But I wanted to verify that the SamsungTV way is broken/unfinished.

Maemo is very much like SamsungTV (as opposed to WinCE) in that it is based on OSystem_POSIX as opposed to OSystem_SDL directly (Maemo is linux)
-- 
Tarek

SamsungTV event mapper works.

On 2011-07-06, at 06:13, Tarek Soliman wrote:

> On Wed, Jun 29, 2011 at 05:43:08PM +0300, Eugene Sandulenko wrote:
>> it would be better to sync
>> into implementing it properly, e.g. continue with hack implemented by
>> WinCE or Symbian port, where keymapping is hardcoded in the backend,
>> or do it in a proper way and invest some time in our unfinished
>> KeyMapper code.
> 
> I am not sure what the current status of the keymapper is.
> 
> I have started doing this in https://github.com/tsoliman/scummvm/tree/maemo-cleanup.
> Specifically: https://github.com/tsoliman/scummvm/commit/bafe2bcf60d63e14bfea7e66da12940159ca556c
> 
> I've seen that the SamsungTV backend implements SamsungTVSdlEventSource::remapKey(SDL_Event &ev, Common::Event &event)
> Is that the unfinished keymapper code?
> I can't get this to work; that code never gets hit.
> 
> I am going to have to resort to the WinCE "hack" which I am assuming is to override SdlEventSource::pollEvent(Common::Event &event)
> But I wanted to verify that the SamsungTV way is broken/unfinished.
> 
> Maemo is very much like SamsungTV (as opposed to WinCE) in that it is based on OSystem_POSIX as opposed to OSystem_SDL directly (Maemo is linux)
> -- 
> Tarek
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>

On Wed, Jul 06, 2011 at 06:55:43AM +0200, Pawel Kolodziejski wrote:
> SamsungTV event mapper works.

Thank you so much!

I looked into my problem further and found it was not going to my custom main due to a bug.
It is working now.

I am not sure why there are some defines that have underscore padding __FOO__ and some don't FOO.
-- 
Tarek