XALF

X11 Application Launch Feedback

Xalf: Background and developer information

Why?

Feedback is important in all User Interfaces. Starting large applications in X11 can be a bit confusing, because no feedback is given and it takes a long time before the application shows. Newbies tend to click the icon (for example) a second or more times because they thought it didn't work the first time.
 

How?

1. Detection of when an application has finished loading

At first this problem seems easy, but it's not. One may think that it's just a matter of waiting for the window to show up, but the problem is that when an new window is mapped, one does not know if this is the window of the newly launched application or something else. Some different approaches has been suggested, depending on how the functionality wanted:
  1. The feedback indicator only behaves correctly when loading a single application without doing anything during the load time. This is the easiest case. The indicator changes when the app starts to load, and is changed back to normal mode as soon as any window is mapped on the screen. This technique is used by   Busycursor 0.3. and CDE (which also resets the indicator after five seconds if no window is mapped).

    2.  
  2. The indicator behaves correctly even when loading multiple apps at the same time, but only if loading different types of applications. For example, one can load Netscape and Xterm simultaniously but not two Xterms at the same time.

    3.  

    This mode can be implemented with assistent of the window property WM_CLASS. An helper application examines all new mapped windows and checks if they have correct Instance- and Classnames, and resets the indicator if this is the case. One big problem is that the helper application must know what WM_CLASS the app will set. Gnome and KDE apps seems to set the Instance name to argv[0], but in many cases this is not true. The conclusion is that checking WM_CLASS is not a practical solution except in some special cases. Window Maker is such a special case. It can do Docking of applications. This means that you can create an launch shortcut to an running app. In this case, the WM_CLASS (and more) properties are known and can be saved in the launch icon properties. This works good but is, in my opinion, not flexible enough.
     

  3. Correct behaviour even when loading multiple apps of the same type.  This means there must exist some mechanism to distinguish the new windows from each other. The SCWM people came up with an interesting idea: Why not overload the XLib functions XCreateWindow and XCreateSimpleWindow? When these are called, one can also set some window properties to uniqely identify the window. An implementation of this idea, called pidproperty, is included with the SCWM source code. It sets a property called SCWM_RUNNING_PID to the application PID and optionally the property SCWM_OTHER_ID to the environment value with the same name.

    4.  

    First it may seem that the PID is a good enough solution, but it's not. Consider the shell script:
      

    #!/bin/sh
    xterm
    The PID returned upon launching is the PID of the script. Xterm is given another PID, unknown to us. The ability to pass an arbitrary string is more useful. By setting this environment variable to an unique identifier, we can uniqely identify newly mapped windows! This seems to be a solution that works in all (?) cases.

    How to overload the XLib functions? Of course, it's always possible to actually patch XLib. Another way is to use LD_PRELOAD. This seems to work well.
     

  4. Summary / Working solution (?)


    5. Update: xalf-0.2 overloads XMapWindow instead of XCreateWindow. Also, the window property XALF_LAUNCH_ID is not used: XMapWindow sends an signal to the xalf process instead. See xalf sourcecode for details.

    1. The launcher (Gnome Panel, KDE menu etc) launches the application. It inherits an environment variable called XALF_LAUNCH_ID (or similiar) with an unique value set by the launcher. The value can be choosen in round robin fashion (eg. starting on one and incrementing one for every new launch).
    2. The modified XCreateWindow sets the window property XALF_LAUNCH_ID just after the window has been created.
    3. The launcher examines all new mapped windows for the XALF_LAUNCH_ID property. If it exists and is equal to the value belonging to any of the current launching apps, we have found a match.

2. Presentation of feedback

1. One shared indicator for all apps in launching.
 
Solution Good Bad
Add an hourglass to the mousecursor Users tends to look at the mouse cursor, and quickly sees the indicator. Either holds:
1) The cursor changes only on the root window, panels etc. This means the indicator will not be visible if the user moves the cursor to another application. 
2) The cursor changes in all windows (possible?). This will be confusing.

2. Separate indicators for each app in launching
 
 
Solution Good Bad
Add an icon to a pager (for switching between apps) which somehows indicates that the app is starting up. The indicator is always visible (as long as the pager is visible). Operations can be performed on the not yet started app, for example suspension or killing.  Users may not notice the indicator. 

Some Links

Last modified June 2000