Re: galf once more: application launch feedback

[Peter Åstrand <astrand lysator liu se>]

On Wed, 18 Apr 2001, Mary Dwyer wrote:

> I've added galf (Gnome Application Launch Feedback) as a module to Gnome CVS in
> order to let people have a look at it. The README and TODO files should provide
> an explanation of how galf works.

Elliot Lee wrote:

>Hmm, sorry to bother you again, I could not find a requirements list that
>was used to arrive at the design, so it is hard for me to say whether my
>objections are valid.
>
>Assuming the only requirement were to notify the launching app of the
>presence of the GUI for the launched app, I would personally choose a
>design where the launched app just sent an X client message directly to
>the window of the launching app. This is extremely simple, totally
>interoperable, and also relatively easy to retrofit into existing
>launcher and launchee applications.

Here is my view on this:

There are three components in this system:

* The central feedback server
* The binary wrapper
* The launched application

As far as I know, most people have agreed on an arcitecture like this. An
central feedback server is more elegant and gives more possibilities than
having to run a "tracking process" for every launched application (like
with Xalf).

These components need to communicate in two ways:

1) The wrapper needs to inform the feedback server that a new launch has
begun. This message must contain an unique string, the feedback-mode
(mappingmode or native) and some other things, like a titlestring etc.

2) The application needs to inform the feedback server when it has
"started" (whatever that means). The best place to do this (results
previous discussions) are in the Toolkit (for GTK+, this means
gdk_window_new or similiar). The message must contain the unique string
created from the wrapper earlier (passed by an environment variable).

So, now that we now what to say (the communication that must take place),
we can think of how to do it.

For message 1), we can use for example CORBA, SysV IPC, fifos, IP,
XClientMessageEvents or setting/changing window properties. We should
probably use an network-transparent method, so we can use the wrapper on
non-local hosts (eg. a host different from the feedback server). IMHO,
CORBA and XClientMessageEvents are the only reasonable solutions. I tend
to like the XClientMessageEvents better than CORBA, since its less
complicated. Also, XLib are more common than CORBA on systems, so this
means the wrapper will be more portable.  Drawbacks with
XClientMessageEvent?

* We can only send 20 bytes in each message. But this should do it I
think, or we can use several messages.

* We must know a X Window ID of the central feedback server. This isn't a
bit problem, here.


For message 2), it's even more imporant that we use a simple method. To
me, using XClientMessageEvents or setting/changing a window property seems
good. Lets look at these two methods more closely:

XClientMessageEvents: The problem with finding the feedback server window
applies here also. This means a few extra lines of code to gdk_window_new.
Besides this, XClientMessageEvents seems a good choice here also.

Setting/changing a property (like _NET_WM_LAUNCH_ID): Easy to implement in
toolkit, but a lot more work has to be done in the feedback server. The
problem is applications like GNOME Control Center, which does not create
any new toplevel windows. If the feedback server should be able to look
for _NET_WM_LAUNCH_ID on all new windows, this means (as far as I
understand it) that it must listen for XPropertyEvents on more or less
*all* windows. Not very nice.

IMHO, the XClientMessageEvents is the best solution also for message 2).

This means CORBA will be unnecessary for galf.


Comments?

-- 
/Peter Åstrand <astrand lysator liu se>