From kde-core-devel  Mon Oct 25 21:37:18 1999
From: Rik Hemsley <rik () kde ! org>
Date: Mon, 25 Oct 1999 21:37:18 +0000
To: kde-core-devel
Subject: App starting+started indication
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=94088756918096

I have implemented a system for giving the user feedback when an app is started.

This is a rather naïve, first-try implementation, but it works well and may
actually be close to how it 'should' be.

There follows a discussion of the reasons for the design from the user's
point of view, then a discussion of the implementation.

* From the user's perspective:

  When an app is started, a taskbar entry appears _immediately_. This entry
  starts off with some indication that the app is starting up.
  
  Currently this is simply the executable name with ' ...' appended.
  I will change this to something a little more consistent.
  
  Perhaps this will be a spinning kog where the appicon should be and the
  'correct' name of the app.

* Implementation

  - kapp
    
    kapp takes an extra command-line parameter, '-kdeid id:of:app'. This
    parameter is split into three.
    1. Executable name.
    2. PID of app that started the process via KRun.
    3. Unique id within app that started the process.
    
    So if you start kedit via KRun, the parameter might look like 'kedit:232:3'.

  - krun
    
    krun adds the extra parameter to the command line for every executable
    it runs. It also sends a DCOP call to kicker, telling it to create
    a new 'pending' taskbar entry.

  - kicker

    kicker receives 'addPending(QString)' and adds a new taskbar entry.
    This happens immediately before KRun actually executes the app.

    When the 'appStarted(QString)' signal is sent by kapp, the taskbar
    entry is turned into a 'proper' entry.

    If an app crashes before KApplication::parseCommandLine() the taskbar
    entry will not go away, so I added a timer to kicker's taskbar to remove
    apps that haven't signalled that they have started.

Ok, so this does what we want. The user has feedback to show them that
an app is starting up. When the app is running, the taskbar entry changes
accordingly.

Problems:

* DCOPClient is created in kapp
  
  Solution: You tell me. Is it a Bad Thing ? kapp may have a slightly slower
            startup. I didn't measure it, but it didn't make any noticeable
            difference.
            Note: It's perfectly possible to delete (or restore to previous
            state) the DCOPClient after use, so we're not wasting memory
            or interfering with anything else.

* An extra parameter is added to every KDE app.
  Why is this a problem ? Well, are apps _always_ started by KRun ?
  Obviously if you start an app from the command line then you're on your
  own. Users should not be doing this.

  Solution: I don't know, and I don't know if it is really a problem.
  
* This doesn't do anything at all for non-KDE apps.

  Solution: Use an environment variable to give apps the kdeid. Write a
            tiny program that sends the appStarted() signal to kicker.
            
            Have apps call do something like:
            QString kdeid = getenv("KDEID");
            system("tell-kicker-I-started " + kdeid);
            
            I'm sure this will be possible in apps like Vim, Emacs, etc,
            without patching the source.
            
            As for GNOME apps (I really want to set a standard here), they
            could simply call something like the above (from GnomeApp, if
            there is such a thing) or they could talk to dcopserver in
            a similar way to kapp.
  
* appStarted() signal is sent before app has actually mapped to screen.

  Solution: Put it in KTMainWindow ?

One idea I had was to save the pid of an app as it starts and wait for
XMapEvent. Unfortunately, not being an X guru (or an anything guru) I don't
know how you'd find the pid of that app that 'owns' the mapped window.

If there was a way to find the pid when a MapEvent happens then the DCOP
stuff in kapp would be unnecessary and it would be easier to handle non-KDE
apps.

Any suggestions welcomed.

Cheers,
Rik