Re: [maemo-developers] hardware keys -- proposal for alternate XKeys
On Mon, Jun 12, 2006 at 12:10:39AM +0300, ext Kemal Hadimli wrote: with the IT2006 (great beta btw!) getting ready, any hope we could get this implemented? imho this is important for thin client functionality, especially for fullscreen terminal apps (rdesktop/vncviewer) Not for IT2006, sorry. It's on my radar though; I'll have a look at it. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] hardware keys -- proposal for alternate XKeys
Hey, with the IT2006 (great beta btw!) getting ready, any hope we could get this implemented? imho this is important for thin client functionality, especially for fullscreen terminal apps (rdesktop/vncviewer) On 3/27/06, Florian Boor [EMAIL PROTECTED] wrote: Hi, Kemal Hadimli wrote: Move the hardware keys to unused XKey values. This way, with the F keys free, apps (mostly the ones that are supposed to be used with bluetooth keyboards, like vncviewer/rdesktop) can use them freely. basically a good idea. We try to do this on other platforms for the special keys too, but sometimes you can run into trouble with this. (e.g. some versions of kdrive are missing some key definitions. It might be worth to think about using the higher function keys (F12) for this purpose. In this case it would be just a matter of shipping an Xmodmap file matching your device. -- Kemal ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] hardware keys -- proposal for alternate XKeys
Hi, Kemal Hadimli wrote: Move the hardware keys to unused XKey values. This way, with the F keys free, apps (mostly the ones that are supposed to be used with bluetooth keyboards, like vncviewer/rdesktop) can use them freely. basically a good idea. We try to do this on other platforms for the special keys too, but sometimes you can run into trouble with this. (e.g. some versions of kdrive are missing some key definitions. It might be worth to think about using the higher function keys (F12) for this purpose. In this case it would be just a matter of shipping an Xmodmap file matching your device. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-14 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] hardware keys -- proposal for alternate XKeys
Hello,
With the current hardware key arrengement in maemo, using some special
keys (F4...F8) in external (read: Bluetooth) keyboards is a problem.
It's not apparent with daily applications, but with fullscreen apps
that require full keyboard support (think using rdesktop/vncviewer
with a BT keyboard), it becomes an issue. The user wants to send an
F4 key to the running application, the menu pops up instead. If the
app isn't a full blown hildon app (ie. using bare xlib) then the user
can send F4, but now the hardware key Menu has no use. (sidenote --
of course for an app to support the menu key it has to be
hildonized)
Proposal:
Move the hardware keys to unused XKey values. This way, with the F
keys free, apps (mostly the ones that are supposed to be used with
bluetooth keyboards, like vncviewer/rdesktop) can use them freely.
Loud thinking:
This could be fixed in a maemo release, or this could be optional.
Making it optional wouldn't break the precompiled apps, but I'm not
sure if that's enough to keep broken code in maemo. For instance, an
application could send a D-Bus message, requesting the new hw key
method to be activated. And after that message is received by hildon,
the hardware keys sent to that application would be the new key
sequences.
STRONG suggestion:
In the future, a hildonGetXKeyValue() (don't you just love
pascalCasing) type of function should be implemented. This function
should be used in applications instead of macros for determining
hardware key values. This way, when the key values change again in a
future release it wouldn't be a problem for the current binaries.
Optionally, apps should be free to cache the keyvalues (ie. querying
the key values at initialization and using the prequeried values in
event handlers) for optimization purposes. The codebase might look
something like this:
typedef enum {
HILDON_HOMEKEY = 0,
HILDON_MENUKEY,
HILDON_ESCKEY,
HILDON_LEFTKEY,
HILDON_RIGHTKEY,
HILDON_UPKEY,
HILDON_DOWNKEY,
HILDON_ACTIONKEY,
HILDON_FULLSCREENKEY,
HILDON_MINUSKEY,
HILDON_PLUSKEY
} HildonKey;
XKey hildonGetXKeyValue(HildonKey hk)
{
XKey ourkey;
/*
Insert code here that looks up the real XKey (or GdkKey) value of HildonKey
*/
return(ourkey);
}
A possible combination for the keys is:
XK_Prior and XK_Next for the rocker keys (+/-)
XK_Select or XK_Execute for the D-pad middle key (might not be necessary)
XK_Menu for the menu key
XK_Cancel for the ESC key (might not be necessary)
and so on (look in /usr/X11R6/include/X11/keysymdef.h for possible
keyvals, there are a lot of them)
--
Kemal
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
