[Galago-devel] [pynotify] Replace notifications created by another process

[RazZziel]

Hi, thank you for the support :)

I'm working in a daemon for klik (http://klik.atekon.de/) that watches
(with inotify) a "Applications folder" for new applications, and when
a new package arrives, it executes a python script (almost all the
codebase of klik was done in python when started the daemon) to
register the new application in the menu. When a package is
registered, a notification is displaied.

The problem is that, even if inotify is able to register groups of
changes, when installing more than one applications to the
"Applications folder" at once, inotify is not able to send them all to
the python script. It sends them in packs of 3, 2 or 1 applications.
The python script displays a notification for each call, so it will
display one notification for each group of 3, 2 or 1 applications,
which is kinda ugly if we are registering around 10 applications in
less than a second. Not a big deal, but it would be nice to be able to
get really clean notifications. My goal was to be able to update the
previous notification, adding the last menu entries.

However, if getting the ID of an existing notification is not already
possible, I suppose I could workaround this in other way, for example:

- Move the daemon to the python side of the application, but I was
doing it in C++ to make it as lightweight as possible. I tried to
write it in python, but the memory footprint was some magnitudes
bigger.
- Call the python script disabling the notifications and implementing
them in the C++ side, so I'd be able to save the last notification
object to "update" the popup. This solution would add another
dependency to the daemon (in the python script we can simply "do
nothing" if the pynotify library doesn't exist), and it would be much
harder to track the names and icons from inside each application
package (it's already implemented in python)
- ...or maybe, in the python side, I can use dbus instead of pynotify
(if only dbus is able to address a notification by its ID), save the
notification ID and its body to a temporal file, and let the next
instance of the python script try to reuse the previoud notification.
However, how could I either remove the file when the notification
expires, or test if a notification with an specific ID is being
displaied, to avoid reusing a non-existant notification?

Greetings

On Dec 2, 2007 10:41 PM, Christian Hammond <chipx86 at chipx86.com> wrote:
> Hi.
>
> There's nothing in place for getting a notification's ID through either
> d-bus or pynotify. You would have to somehow share the ID between instances
> of your program in order to replace the notification. It's such a rare
> usecase that I don't know that it should go into the notification spec (plus
> it's prone to abuse and to problems, such as if two notifications shared the
> same header text).
>
> What's the goal of the daemon and the python process? Can the process
> somehow use the daemon to grab a notification ID for use, or go through the
> daemon to emit notifications (allowing the daemon to track the ID)?
>
> Christian
>
>
>
> On Dec 2, 2007 4:23 AM, RazZziel <razielmine at gmail.com> wrote:
> >
> >
> >
> > Hi, I'm working on a program in Python that can be executed by a
> > daemon several times in a second, producing a notification in each
> > execution.
> >
> > Now, each notification is overlapped to the older one, but I would
> > like to make each notification update the older one instead, following
> > the behaviour obtained by update on pynotify, or by the replaces_id
> > fieldd in dcop. Would it be possible to make this work through
> > different program instances? For example, a dcop call that detects if
> > there is any notification being shown, get its header to see if it's
> > mine, get its body and concatenate the new information to the older
> > one. Or maybe an undocumented pynotify function.
> >
> > Greetings
> >
> >
> >
> >
> > --
> > ...yet even then, we ran like the wind, whilst our laughter echoed,
> > under cerulean skies...
> > _______________________________________________
> > galago-devel mailing list
> > galago-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/galago-devel
> >
>
>
>
> --
> Christian Hammond - chipx86 at chipx86.com
> VMware, Inc.



-- 
...yet even then, we ran like the wind, whilst our laughter echoed,
under cerulean skies...