Notices

@Helmuth, nicely written

There is only me and @hqh on this at the moment (we actually need to get down to some real work this week, mine exams are over).
I was thinking recently about separating a pure proximity sensor daemon from the shortcut application.

I'm thinking about having a proximity sensor daemon, polling the sensor and sending a dbus signal whenever the change in the sensor state is registered (also support reading on demand). This way we would have a nicely behaving dbus architecture, consistent with the rest of the system (why the hell proximity sensor is not connected to dbus by default?!).

This will be used in our shortcut application, but can be also easily used by different application. Then, our application functions can be modified by exposed dbus calls, so your app can explicitly request turning off shortcut handler. Plus, second option, our app can act as a middle-level abstraction and emit dbus 'short-press', 'long-press' (or just emulate key-presses), or handle 'keyboard-locked-don't-emit' functions.

This way, you can either access the sensor directly, telling the shortcut daemon to turn-off, or access the sensor with an abstraction of key-presses (including camera key, those two options require modification in your code) or just request given key (combination) to be simulated (this doesn't require changes in the code of your application).

Thoughts about this?

great stuff fanoush!

menu and everything work like a charm

only thing I've noticed by starting up the dig and saving the game is, that I wasn't able to type numbers for the savegame, somehow the fn key does not work here

Thankyou. :-)

[...]
Hmm... I'm not sure. But I guess there are more shortcuts needed by ScummVM than could provided thru your daemon. And only send a "short pressed" or "long Button press" is not enought to provide a posibility to enable right mouse click during holding the camera button down.

A "Button_pressed" and a "Button_released" event from your daemon could provide something like this.
I think we wait for a comment and some thoughts from fanoush. He have done the last modifications on the ScummVM and he knows the Code behind even better than me. I have only seen a short quote here in maemo talk.

I would love a self-explanatory solution. Even simple simple simple.
We have a touchscreen. We should try to avoid keeping a list of shourtcuts with us.

Isn't it possible to contact the developers of ScummVM (I don't mean the port for Maemo here) and ask them what or if they could do something for portable devices like the N900? Maybe they know a good solution...

You are already talking to one of them :-) Well, actually, I am currently the only one (ScummVM porter to Maemo). No problem if someone wants to join. ScummVM project knows about these problems, see http://wiki.scummvm.org/index.php/Small_Devices_Backend Last time I checked it was not ready yet but maybe it is about time to check it again.

Works for me. You need to hold fn, it is not sticky in most/all games based on SDL. The sticky shift and fn feature is implemented on much higher level of Maemo so it is not available to SDL (and all pure X11?) applications.

Just quick comments. ScummVM for Maemo is currently using SDL library. d-bus etc is not available to SDL. The easiest in current state is to get ordinary events (key presses, mouse events).

Maybe in future I can try to start another thread from inside scummvm and initialize glib etc. and listen to d-bus events in parallel to SDL event loop (mainly to support power management better) but it is not trivial. Actually in that case maybe abandoning SDL and starting from scratch would be easier and allowed more flexibility. It is a lot of work though. Also I like current state where all Maemo devices running OS2006,7,8,maemo5 can run same scummvm binary compiled from same source code. Supporting each device and each Maemo version separately is more work too.

On-screen buttons/switches/virtual keyboard is likely once ScummVM engine itself allows me to do that without writing all the code myself (reinventing the wheel). As for various device sensors etc. doing it outside of scummvm means other SDL game ports can use it too.

great work where do i install the games too? which directory? cheers

@fanoush, thanks, key/mouse event it will be for ScummVM

[...]
Hmm... I can understand what you're talking about. It's not so easy and a lot of ungrateful work.

So my second suggestion in post #90 could work without changes in a easy enought way?
Or are there limitations avoiding something like this?

I think about a menu tat appears like the Menu when you press the power Button on the N900 once. Only click a Button and send the needed keycode to the running scummVM without changes on the scumm code. Everything we need is covered with keycodes.

The Menu from the Power Button is also not from a running programm, it appears from a background working daemon or service. (Sorry, I'm not sure with the correct linux term)

So there could run the same OS2006,7,8,maemo5 binary and with a additional daemon like the one from hopbeat or with exactly this we could have such a feature on the N900.

Am I right or totally wrong?