Re: [iPAQ] Buttons and applications

>How about a "button daemon", that keeps track of window focus and button
>presses, assigning the proper code to the proper app? If this were done at
>the X server level, it would be pretty transparent.
>
>It may be that we need a more general "input daemon" that accepts input
>from the buttons, fscrib and the on screen keyboard, then passes the proper
>code to the proper app.

I like this as an idea. It seems to meet that the keyboard should be able
to operate in a similar way to fscrib, ie. it should know which window has
the focus. The keyboard/fscrib should operate from the task bar (although
there isn't a huge amount of space). If all keyboard handling is proxied
via a single process we will be able to get a tighter handle on the input
being sent to applications.

At the moment, using fscrib and the keyboard can be a little confusing as
they can be focused on different windows.

>
>As for using the buttons to lauch apps, it pretty much has to go
>hand-in-hand with talking to apps. The same buttons are used for both.
>

Are we saying that the buttons will launch the default applications unless
the currently focused app has redefined their use? It seems fairly obvious
that the joypad should map to the cursors and the centre should map to
either Return or KP_Enter (I prefer Return as it is recognised by rxvt).

>Basically, I think we need to go with a "keyboard model". Button one, say,
>is mapped to Alt. If no window has focus (maybe an empty screen in the
>active workspace), button one (Alt) lauches the PIM suite. If an app
>running a game has focus, button one (Alt) performs a game related
>function.

I think Alt is tricky as it is a keyboard modifier (ie. it alters the
meaning of another key). I would be more inclined to map the 5 buttons to
F1 through F5. It seems more 'the right way'.

>IMHO, this should not be hard to do at the X server level. The hooks are
>all there. The server knows what has focus. It reads the button press,
>sees window xxx has focus, looks up the proper code and passes it. If no
>window has focus, it lauches the app mapped to the button.

It certainly sounds like the way to go. Have a single program capture the
buttons, provide the on-screen keyboard and also handle handwriting. I also
think this app should be integrated into the taskbar, rather than the
menus. I do like the way the keyboard is a popup at the bottom of the WinCE.

>Whichever way we go, this all needs to be done together. We have a hacked
>hodge-podge that works pretty well now. If we redo it all, lets do it the
>right way.

Exactly. The hacked version has served us well but I think it is time to
move on.

>JG and Keith need to be involved here. I'm sure they can either back me up
>here or slap me down with the facts...
>
>Tom
Received on Mon Feb 19 10:21:48 2001