[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    app-start notification II
From:       Rik Hemsley <rik () kde ! org>
Date:       2000-05-18 13:51:24
[Download RAW message or body]

The original app-start notification system was a little hackish. It used
X hints to find out which window belonged to which application.

I've now taken the idea used by SCWM and xalf, and written a tiny
library that, when loaded via LD_PRELOAD before starting an app, will
intercept XMapWindow and XMapRaised calls, sending a DCOP signal to
kicker, with the pid of the app that caused the event.

Basically you do 'LD_PRELOAD=${KDEDIR}/lib/libkmapnotify.so execname'
to run an app with notification. This is done automatically by KRun.

The problems I have at the moment are:

* It needs to link to libDCOP (not a problem) but also libqt, required
  by libDCOP. This slows down app start for non-qt-based apps as the
  symbols in libqt have to be resolved.

* I'm not sure what the correct syntax is for saying 'link to libdl'
  in the Makefile.am - I'm just using -ldl appended to LDFLAGS at the
  moment.

* Netscape Communicator 4.7 crashes when the netscape wrapper script
  provided by SuSE (SuSE Linux 6.4) runs. This seems to be related to
  the fact that the wrapper script adds another library
  (libBrokenLocale) to the LD_PRELOAD list.

* Apps started with kdeinit do not have notification.

* Starting konqueror via the 'home' button on kicker gives no
  notification (presumably because it's using kfmclient).

* Starting konqueror via the 'home' menu entry in kicker's 'K' menu
  gives the 'starting' button, but it doesn't go away at the right
  time. I couldn't find how kicker is starting konqueror in that
  case.

These minor problems aside, the new way beats the old in that it doesn't
fail when an app doesn't set its WM_CLASS/res_name to the name of its
binary.

If anyone can help me with any of these problems, it would be much
appreciated.

It may be possible to use shm to send out a signal, to avoid linking to
libDCOP (and therefore libqt), but I don't think this is the best
solution to that problem.

Rik

[prev in list] [next in list] [prev in thread] [next in thread]