On Wed, 2007-04-25 at 23:23 +0200, [EMAIL PROTECTED] wrote:
> On Wed, Apr 25, 2007 at 09:27:22PM +0100, Rob Bradford wrote:
> > Martin, Mickey,
> > 
> > You are indeed right in spotting that X properties is probably the wrong
> > thing here. I think the nicest solution is to synthesise the appropriate
> > X events like you would expect from a scroll wheel (e.g. button 4/5).
> > This also makes it easy for a process to hook into these in a widget
> > specific way rather than having to work it out yourself.
>       You are exactly right. Using standard way like scroll event and
>       button events is good solution.
>       Maybe button 4/5 for scroll and some keyboard buttons like F20-F22
>       for toolbar buttons, keeping mouse buttons for touchscreen.
> > 
> > The other problem is how to know when to show this toolbar,
> > set a _MOKO_FINGER_CONTROLS=[0|1] on the root window, or something, we
> > can worry about this later.
>       I am not so shure about this. Anyway you need to set icons on
>       buttons. I think, that for setting properties and showing/hiding
>       will be D-Bus good solution.
>       

I didn't realise that the toolbar was program specific. I think dbus
should be used to setup the contents of the toolbar but actually, the
best way to show/hide would be to track the _NET_WINDOW_ACTIVE property
on the root server and then check if the top window is tagged
_MOKO_FINGER_APP and if so show the box else hide. This is much easier
than trying to get an event when the window is made active/made
inactive.

The client sound send a dbus call to the toolbox of the form 

register (window id, toolbox data....)

and then when that window is noticed to be made active then the toolbox
is updated. If the process is changed then the toolbox is changed to the
toolbox for the new program, but the old toolbox is kept cached for when
the window is made active again.

When a program is closed then it can simply do

unregister (window id)

Sounds good?

Cheers,

Rob


Reply via email to