Re: App-starting notification

[Havoc Pennington <hp redhat com>]

Hi,

I'm quoting your entire message and CC'ing wm-spec-list, since they
will certainly have an interest in this.

Sounds like a good idea to me (in principle at least, I'm not very
educated on the technical details). Should this be in the window
manager spec? Or should it be a separate spec?

Havoc

Rik Hemsley <rik kde org> writes:
> Hi,
> 
> According to the NET_WM standard, apps may set the _NET_WM_PID atom to
> advertise their pid. This allows for a notification mechanism whereby the user
> is informed that an application has been started (execution may not actually
> have begun), and then informed that an application has loaded (it has mapped a
> window).
> 
> It's simple to make sure that all KDE apps set the _NET_WM_PID atom on the
> first window they map. This is done automatically by the KApplication class in
> our core library.
> 
> Not so simple is getting non-KDE apps to provide similar notification. I
> started with a similar solution to that used by Window Maker, i.e. using
> WM_CLASS.res_name. This did not quite work correctly. Apps that did not use the
> standard convention of setting res_name to exactly that of their associated
> binary would not be recognised. This was worked around somewhat by using an
> extra field in a .desktop file, but was still slightly unreliable.
> 
> The next method I tried was similar to that employed by scwm (I think), where a
> tiny library was LD_PRELOAD-ed. This library was used to override the
> XMapWindow and XMapRaised functions from libX11. This solution works very well
> until you try doing something 'out of the ordinary', such as loading a
> libc5-based binary on a glibc-based Linux system or loading a Linux binary on a
> FreeBSD system (e.g. Netscape).
> 
> I've come to the conclusion that the cleanest way to implement this is going to
> be to ignore all non-compliant apps. If only KDE did this, though, then GNOME
> apps would not work with the mechanism. I don't know if GNOME uses some form
> of app-starting notification already, but I'd like to collaborate.
> 
> Here's how the notification works in KDE at the moment:
> 
> * Service 'kwrite.desktop' is to be started.
> 
> * The executable is started and the pid of the running process noted.
> 
> * The desktop file is examined to see if key "MapNotify" exists.
> 
> * If the key exists and the value is "true" then a signal is sent
>   to the panel's taskbar object, informing it of the name of the
>   application and the pid.
> 
> * The taskbar creates a new button, showing that the application
>   with the name given is starting.
> 
> ....
> 
> * The application maps a window. This window has the _NET_WM_PID atom
>   set thanks to a function in libkdecore.
> 
> * When the taskbar applet is informed that this window has mapped, it
>   matches the pid with that of a button it has created. The button is
>   replaced with the usual style of button.
> 
> Note that the method for signalling that an application has been started
> may be entirely different for GNOME. I am not familiar with any IPC mechanism
> used.
> 
> Note also that we use the taskbar because it seemed a logical place to
> put the notification. The user expects to see the task appear on the taskbar,
> so showing a taskbar button with a spinning disk icon seemed fairly
> appropriate. Of course it's entirely possible to use whatever mechanism
> you like, including an hourglass cursor etc.
> 
> Here's what would need to change on a practical level:
> 
> * GNOME applications should _NET_WM_PID atom on the first window they map.
>   I am not sure how this would work in Gnome. If all apps link with a core
>   library then it is trivial.
> 
> * The desktop entry standard gains a new entry, "MapNotify".
> 
> I know that this solution will not work for non-compliant applications,
> but at least with GNOME and KDE apps working the same way a standard would
> be set, which others would feel oblidged to follow. The implementation
> in an individual application is extremely trivial - a one-liner :)
> 
> Comments welcome.
> 
> Rik
> 
> 
> _______________________________________________
> gnome-kde-list mailing list
> gnome-kde-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-kde-list