Re: patch for gtk+-2.0 : support for new Application Launch Feedback mechanism

[Mary Dwyer <Mary Dwyer sun com>]

hi

>Requirements:
.....
>2.  The feedback mechanism should work for Gnome and non-Gnome applications.

perhaps the wording was unclear, but support for applications using a 
non-compliant toolkit was repeatedly expressed as a requirement when this
project was first discussed on the email aliases. (The example of 
netscape's start-up time was cited as an argument for the neccessity of feedback 
for non-compliant apps).  It was this requirement that 'complicated' the design.

cheers
Mary

> 
> On Wed, 21 Mar 2001, Mary Dwyer wrote:
> 
> > There are problems with your proposal as I understand it:
> >
> > 1. The launcher would:
> >       - start the feedback display
> >       - fork and exec application
> >
> >       But, if the feedback display window is awaiting an X client
> >       message then it would have to use gtk_main(). Therefore, the
> >       start_feedback() would not return to allow launcher to fork and
> >       exec the application.
> > (In galf the feedback display window just
> >       uses gtk_widget_show()).As far as I can see, you would have to
> > use
> >       threads to get around this ......
> 
> I'm really not comprehending the problem here. A description of a sample
> launcher implementation follows:
> 
> During initialization, it sets up a 'client_event' signal handler on its
> main window.
> 
> When it wants to launch an application, it creates an ID number to
> internally identify that instance. It forks, and in the child does
> setenv("DESKTOP_LAUNCH_ID", "launcher_main_window_ID,launchee_ID"), and
> execs the application. The main launcher process then can sit around
> waiting for the launchee notification, or can timeout if no notification
> is received.
> 
> > 2.  The mechanism you propose relies on the toolkit being compliant (ie
> >     sending the X client message). The galf mechanism has a workaround
> >     for non-compliant toolkits (ie toolkits that do not set the
> >     _NET_WM_LAUNCH_ID property), in that it monitors for the mapping of a 
new
> >     window that does not have that property set.
> 
> The requirement of dealing with non-compliant apps was not given. If this
> is in fact a requirement, this will certainly complicates things, and
> might make the X part of the current design necessary (there is no benefit
> to requiring a notification message from the launchee if you are going to
> have to be examining all the new windows shown anyways).
> 
> > Can you outline the issues/problems you envisage with the CORBA solution?
> 
> Can you explain what functionality CORBA adds that cannot be done in the
> launcher by a library?
> 
> Thanks for your patience :)
> -- Elliot
> The truth knocks on my door, and I say
> "Go away. I'm looking for the truth"
> ...and so it goes away.
> 
> 
> 
> 
> 
> 

~ 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=