Re: running this by you: Application Launch Detection for Gnome
- From: Peter Åstrand <astrand lysator liu se>
- To: Mary Dwyer <Mary Dwyer ireland sun com>
- Cc: <gnome-hackers gnome org>, <gnome-gui-list gnome org>
- Subject: Re: running this by you: Application Launch Detection for Gnome
- Date: Sun, 4 Feb 2001 22:47:02 +0100 (CET)
On Wed, 31 Jan 2001, Mary Dwyer wrote:
> I was involved in email discussions at the end of last year on this subject with
> Peter Astrand (author of Xalf), Owen, Havoc and others on some gnome-aliases.
> 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
...
>3.The gdk library has been edited so that if the DESKTOP_LAUNCH_ID has been
> set then the property _NET_WM_LAUNCH_ID is set on the toplevel window of
> the gtk app.
This looks very good. Since LD_PRELOAD and/or patching Xlib is out of
question, a toolkit-assisted mechanism seems a good solution.
> 1. Visual feedback is controlled by an ORBit server (called feedback-server),
> and client (feedback-client).
A good structure, IMHO.
> 2. feedback-client acts as a binary wrapper around the app to be launched.
> - It sets an environmental variable (DESKTOP_LAUNCH_ID) with a unique value.
> - It then invokes a remote method to start the visual feedback for this app.
> (At the moment this is the tasklist window hacked from the Xalf code, but
> by implementing a pluggable interface here could have customised
> visual feedback).
Also good. This sounds like the correct way to do it. Of course, shells
etc. can of course implement the functionality of the binary wrapper
themselfs, but there must always be a standalone wrapper available.
>A compliance flag indicates whether this is a gnome application or not.
This is one of the most tricky problems. As others has suggested, adding a
special flag to the .desktop files seems like the best solutions. If this
flag is missing or a .desktop file is not available, I think it's
reasonable to use App Start Feedback anyway in the "mappingmode".
Also, we should not distinguish between "gnome applications" versus
"non-gnome-applications" but rather if the app is
"_NET_WM_LAUNCH_ID-compatible" or not.
> 3. The gdk library has been edited so that if the DESKTOP_LAUNCH_ID has been
> set then the property _NET_WM_LAUNCH_ID is set on the toplevel window of
> the gtk app.
Seems good. It would be great if we could agree on this mechanism and get
it into new GTK+ and KDE libraries. What is the status of GTK+ right now,
would it be possible to get a patch like this into GTK+ 1.2.X or is it a
1.4.X thing?
Just one though: Is this solution free from race conditions? Is this
possible:
1) The Xwindow is created
2) The feedback server detects this quickly and checks for
_NET_WM_LAUNCH_ID
3) _NET_WM_LAUNCH_ID is now set
-> feedback server missed _NET_WM_LAUNCH_ID, because it it set to late.
(Another somewhat unrelated question: Why not also set
something like _NET_WM_PID, with the process PID, at the same time? Many
people has been looking for something like this. Opinions?)
Some more thoughts: Maybe it would be useful for applications to tell the
App Start Feedback System that it wants to stop the feedback explicitly.
For example, some apps display the main window quite quickly but does lots
of more initializations. If the app could tell GDK early that it doesn't
want GDK to set _NET_WM_LAUNCH_ID, it could contact the feedback server by
itself later and stop the indicator. Is it possible to implement something
like this? Is it desirible?
To summarize, I like this. Good work Mary :-)
--
/Peter Åstrand <astrand lysator liu se>
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]