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