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

[Mary Dwyer <Mary Dwyer Sun COM>]

hi Elliot

below is an outline of the requirements that were drawn up following the 
discussions on the email aliases a few months ago. One of the requirements was 
to devise a solution which would work for Gnome and non-Gnome applications 
(which, if I understand your last email correctly, would exclude the solution 
that you proposed there?).
If you need any more info to evaluate this just let me know

cheers
Mary




             Gnome Application Launch Feedback Requirements


Design an application launch mechanism to provide feedback to the user on 
launching an X11 application.
-  These requirements incorporates issues raised on gnome email lists 
-  Builds on work done for Xalf design.


Requirements:

1.  The feedback display should be started once the user tries to launch an 
instance of an application, and
      that feedback display must be terminated once that instance of the 
application has been mapped.
2.  The feedback mechanism should work for Gnome and non-Gnome applications.
3.  The LD_PRELOAD soultion (as used in Xalf) should not be used as it has a 
number of problems.
4.   The solution should not involve patching Xlib (as had been suggested in 
email discussions)

See:  http://mail.gnome.org/archives/wm-spec-list/2000-November/msg00019.html



Proposed Solution:

Use a binary wrapper to:
- start a unique instance of feedback display
- fork and exec application
- monitor for mapping of application
- stop that instance of feedback display once the application is mapped.

The feedback instance is uniquely identified by the binary wrapper which sets
the environmental variable, DESKTOP_LAUNCH_ID, with a unique value.
Gdk (and any other compliant toolkit) will then set the property 
_NET_WM_LAUNCH_ID
on the toplevel window of the application being launched.
This property is used to determine if a newly mapped window 'matches' the 
feedback instance - 
if so, that feedback is terminated.
If the application's toolkit is not compliant, then that instance of the 
feedback display is stopped
on the mapping of a window without _NET_WM_LAUNCH_ID set.  This is similar to 
the mappingmode
solution in Xalf (tho' somewhat more exact as it excludes newly mapped compliant 
applications).


An ORBit solution was proposed as it facilitated a solution largely independent 
of application or toolkit.
In other words, it allows for:
- starting feedback
- monitoring for newly mapped windows and stopping feedback (via a oneway 
method)
- and forking and execing the application.




> Delivered-To: gnome-private-members gnome org
> Delivered-To: gnome-hackers gnome org
> X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process 
doing -bs
> Date: Sun, 18 Mar 2001 16:27:44 -0500 (EST)
> From: Elliot Lee <sopwith redhat com>
> X-X-Sender: <sopwith devserv devel redhat com>
> To: Mary Dwyer <Mary Dwyer Sun COM>
> Cc: <gnome-hackers gnome org>
> Subject: Re: patch for gtk+-2.0 : support for new Application Launch Feedback 
mechanism
> MIME-Version: 1.0
> X-BeenThere: gnome-hackers gnome org
> X-Loop: gnome-hackers gnome org
> X-Mailman-Version: 2.0beta5
> List-Id: <gnome-hackers.gnome.org>
> X-BeenThere: gnome-private-members gnome org
> X-Loop: gnome-private-members gnome org
> 
> On Fri, 16 Mar 2001, Mary Dwyer wrote:
> 
> > sorry for the delay in replying - some of my mail went astray today :-(
> >
> > A lot of the discussion on the design took place last Oct/November on the
> > gnome-hackers and wm-spec-list aliases, for a hook to the email thread see:
> > http://mail.gnome.org/archives/wm-spec-list/2000-November/msg00019.html
> >
> > Some issues that arose in providing a solution for visual feedback for
> > application launching were:
> > - problems of using a solution involving LD_PRELOAD
> > - problems of a solution involving the patching of Xlib mapping functions
> > - desirability of establishing a common protocol that will work for both 
gnome
> >   and non gnome apps.
> >
> >
> > With this in mind, the CORBA solution seemed a good idea. It allows the 
binary
> > wrapper to:
> > - start the feedback,
> > - call a oneway method to monitor the root window property _WIN_CLIENT_LIST 
for
> > new windows,
> > - and fork and exec the application.
> >
> > This approach:
> > -  avoids the use of the problematic LD_PRELOAD solution
> > -  provides full support for applications with a _NET_WM_LAUNCH_ID compliant
> > toolkit
> > and
> > - provides support similar to the Xalf mappingmode solution for applications
> > whose toolkits don't support the _NET_WM_LAUNCH_ID property.
> >
> > So, those are the main reasons behind the design and why galf is
> > "doing crazy things like using CORBA? :)".
> >
> > I hope that very brief explanation (and the above email thread) makes
> > sense, if not let me know. Could you elaborate on the problems you
> > envisage in using this approach, or any suggestions for improving it?
> 
> 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.
> 
> -- Elliot
> The truth knocks on my door, and I say
> "Go away. I'm looking for the truth"
> ...and so it goes away.
> 
> 
> _______________________________________________
> 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