Re: Application Launch Detection

[Rik Hemsley <rik kde org>]

On Tue, 14 Nov 2000 16:01:17 +0000 (GMT)
Mary Dwyer <Mary Dwyer ireland sun com> wrote:

> hi
> 
> I haven't fallen off the email thread - I've been keeping track of the ideas put 
> forward and trying to get a picture of what is wanted and how it could be 
> implemented.
> 
> The current thread seems to be:
> 
> 1. avoid use of LD_PRELOAD

A good idea if you want to avoid segfaulting apps.

> 2. do not patch Xlib

A good idea, because it's absolutely unnecessary.

> 3. concentrate on establishing a common protocol that will work for both gnome 		
>    apps and KDE apps (ie KDE apps running under gnome will use gnome visual
>    feedback, and vice versa)

Yes.

>  - To achieve this ensure that gnome apps set the value of the _NET_WM_PID atom
>    on the first window they map (as do KDE apps).

I'm assuming that will be easy for GNOME. We do it automatically via the
KMainWindow class, which 99% of apps use. If they don't use it, there are
separate mechanisms they can use just as simply.

>  - Then a Gnome Launcher process can monitors the _NET_CLIENT_LIST property
>    on the root window. It checks the _NET_WM_PID property of each window and 		
>    stops the matching visual feedback.

Yes.

>    Essential to this is starting a feedback instance identifiable by the PID
>    of the app being launched.
>    But I cannot figure out how/where to start the feedback display instance
>    for the app., i.e. how does the Launcher know the PID of the app being 
>    started? If you launch the feedback display from within the gnome application
>    (eg from gnome_init()) then you lose interoperability with KDE apps.
>    
>    I guess I don't fully understand how the KDE app-launcher starts the         
>    feedback.  Rik's mail to wm-spec-list outlining how it works 
>    (http://mail.gnome.org/archives/wm-spec-list/2000-September/msg00000.html)    
>    specifies that 
>    "the executable is started and the pid of the running process is noted ....
>    .... then a signal is sent to the panel's taskbar object, informing it of the 
>    name of the application and the pid".  
>    
>    Could you give some more detail on how this is done? (bearing in mind I know
>    very little about KDE :-( )

KRun is the class used to run executables. It simply sends a DCOP signal to
kicker's taskbar applet as soon as it has started the process.

QByteArray params;
QDataStream stream(params, IO_WriteOnly);
stream << name << iconName << (int)pid << binaryName << compliant;
kapp->dcopClient()->send(
  "kicker",
  "TaskbarApplet",
  "clientStarted(QString,QString,pid_t,QString,bool)",
  params
);                                                                            

I'm not sure how GNOME does IPC, but I presume it has something similar.

It doesn't really matter if GNOME does this bit differently, but I suppose
we could have a standard way to do it if we want, e.g. with a named pipe.

>    But, am I right in assuming from the various emails that this is the way      
>    forward on this? ie
>    - in coming up with a solution going forward, ignore legacy apps as well as 
>      non-gnome and non-KDE apps (and possibly do a hack for these sort of apps)

Sounds reasonable, yes.

>    - ensure that gnome apps set the _NET_WM_PID property 
>    - have a Launcher process separated totally from the apps, that
>      starts an instance of feedback identified by the PID of the app
>      being launched (how to do this?).

Well, yes. In KDE's case, kicker's taskbar is the thing that gives you
the feedback. Of course anything can give you the feedback if you want,
I could just change "kicker" and "TaskbarApplet" in the above example
to "app-launching-listener" and "listening-object" if I wanted, then
any app could register with DCOP as "app-launching-listener" and create
an object called "listening-object". This way we could implement e.g.
the 'busy cursor' idea. If we really wanted to ;)

>    - The Launcher then monitors the _NET_CLIENT_LIST property on the root 
>      window in order to stop the feedback instance when the app is mapped. 

Yes, kicker's taskbar contains a 'kwin module'. It connects to (Qt) signals
from this module, which tell it useful stuff like 'windowAdded(id)'.

Rik

p.s. I don't appear to be on the wm-spec list. Could someone forward this
there for me ? Thanks.