Re: galf once more: application launch feedback

[Mary Dwyer <Mary Dwyer Sun COM>]

hi Peter

thanks for having a look at this.
I do appreciate that using X is a more lightweight solution, but the stumbling 
block in the design of a feedback mechanism is the need to cater for 
applications using non-compliant toolkits.
In your proposal, if I understand it correctly, you are relying on GTK+ to allow 
the application to signal the feedback server that it has started.  This 
wouldn't allow applications using other toolkits to signal the server.  You 
could, I suppose, use a default timeout for such applications but that doesn't 
really address the problem.


cheers
Mary

> 
> 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>
> 
> 
> 
> 
> 
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 
> 

~ I speak for myself, not for my employer ~
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mary dwyer ireland sun com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers