Re: Idea

[Michael ROGERS <M Rogers cs ucl ac uk>]

>> Any thoughts? Would this work?
>
>Yes it works. 


Damn that was fast!


>I wrote such kind of client - listener communiction support.
>
>I used the X properties/client messages to support that feature.
>It uses XAtoms and shared memory to communicate.
>
>How it works:
> The "client" application has a function which can be called from any
> other application. To register this function an XAtom message is
> send through the XServer.
> All aplications which want to use the function are getting a
> structure with the pointer to a shared memory where the name
> of the function is stored; and a callback function.
> If the callbackfunction is called a X-message is sent
> back to the client application where the real callbackfunction
> will called.


Do you need to use shared memory and pointers? I'm thinking about remote X 
connections. Could the application which displays the menu (call it the 
window manager for the sake of argument) just send a ClientMessage to the app 
which owns the menu (call it the client), describing which menu item to 
activate? Then the client would process this event as part of its normal X 
event loop... if necessary, gdk_events_queue() could be modified so that the 
client message was transformed into a fake GTK menu event. (Just for
consistency/ease of programming at the client end, no changes to GDK are
necessarily required!)

OK, it's a bit hackish using X properties and client messages as an IDL and 
an RPC mechanism, but the new WM spec uses this technique for other
taskbar/pager/window manager/client interactions.

It's just occurred to me that there is a possible race where one app diplays a
client's menu; then (while the first copy is still displayed) another app 
displays its own copy and activates a callback which causes the contents of 
the menu to change (eg Play changes to Stop); then the first app activates 
a menu item which has changed/no longer exists.

Three ways I can think of to avoid this:

1) The client message should contain the text of the menu item, not its index.
If the specified menu item no longer exists, the message will be ignored by 
the client. Disadvantage: if the window manager/taskbar has pinnable popup
menus or some other weird facility, a menu might be visible which contains
obsolete menu items. It won't break anything to select one of them, but it 
will confuser the user.

2) The client draws its own window menu at coordinates specified by the
window manager/taskbar etc in a client message, and the client processes menu 
events (activation etc) directly. Only one copy of the window menu can be
visible at a time (because there is only one window menu). This has the 
advantage of making the client toolkit code much cleaner (a popup window menu 
is presumably much like any other popup menu, except that it's a top-level 
window), but you lose the ability to make the window menu match the window 
manager's theme, you can't merge it with the window manager's "Close, Resize, 
Hide" menu, etc.

3) While it is displaying a window menu, the window manager/taskbar should
listen for property change events on the client's "menu contents" property. It
should ensure that its menu is kept up to date if the menu contents are
changed by the client.

I think a combination of 1) and 3) should be reasonably reliable (?).

>I attached a well working example with that message...

I'll try it as soon as I get home!


Michael