In one of my last posts on libnotify I displayed a notification bubble that followed the widget it was attached to. This is not a big deal with inprocess widgets but since libnotify is out of process it complicates things a bit. The hack I was using with the idle handler turned out to use too much CPU. I could use a timeout but I think it would still present some bigger issues.

You see, the biggest problem is that I don’t get config events (those ones that tell you your widget has moved or resized) because the widget doesn’t move relitive to its parent which in the case of notification icons is the notification area. I don’t think I can recive events from the notification area itself without hacking up the applet. I could be wrong however.

The other problem is some race conditions when the server closes the notification. If I do an update because the x and y changed before I recived the notification closed signal I could very well pop up the notification again when it was supposed to be closed. The fix would be to keep state in both the server and client but that would needlessly complicate things and gear the server twords the libnotify library when it should be library agnostic. This can all wait until after D-Bus 1.0 when state should be introduced on the bus itself. At least we are talking about adding it.

So the solution is to go the simple route and assume the location will not change for the life of the notification bubble. This cuts out having to solve some tough minor issues and getting to the more important ones, even if it does mean a loss of some polish.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]