Display brightness OSD notification
notmart at gmail.com
Sun Apr 11 13:39:05 BST 2010
On Sun, Apr 11, 2010 at 11:26 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Marco Martin at 11/04/10 09:57 did gyre and gimble:
>> i wonder how ubuntu is doing it, perhaps there is an usable dbus intercace?
> There is it's called the desktop notification specification. And it
> already works in KDE (AFAIK knotify implements this specification now
> and if knotify is not running but some other compliant implementation
> is, then it is used in favour of the native one). I've certainly seen
> KDE applications display their notifications via the notification daemon.
oh, i know it does :)
knotify "routes" its -visual- notifications to the
org.freedesktop.Notifications, that is registered by Plasma, so the
notification plasmoid shows in the exact same way notifications from
KDE and non KDE apps in exactly the same way, but is not exactly the
I'm really not sure the notification system is any good for osd.
while i would like to show osd in the same spot as the notifications,
the data it arrives in org.freedesktop.Notifications.Notify() doesn't
seem to fit very well (i would like for instance to be able to show a
progress indicator, to be able to do the kmix one, maybe other widgets
are needed too?)
> So I think this part is basically working.
> That said there are may things *wrong* with the approach Ubuntu has
> taken with this spec (taking an existing, working specification and then
> basically decided not to implement one of the parts that would give true
> cross desktop GUI standardisation.
> I was very annoyed about this approach and still dislike greatly the
> fact they do not implement action callbacks:
yes, i agree, was totally the wrong direction
> That said, this is just their implementation, and AFAIK the KDE
> implementation does implement action callbacks. Personally, if I have an
> app that wants to increase the user experience via the use of "passive"
> popups with some degree of interactive feedback (e.g. a button on the
> popup) then I'd just refuse to work with an implementation that doesn't
> support it and let the user suffer. The Ubuntu guidelines suggest that
> every app should implement a fallback and present their own GUI in this
> case, but for me this is just going to create a myriad of differently
> presented GUIs that completely lack standardisation - especially across
> a KDE/Gnome desktop.
> So my plea is here: don't listen to Ubuntu on this one - use and
> encourage the use of the action callbacks where appropriate. They are
> useful and they provide a nice standard way of operating :)
yes, we pretty much all agree their direction in notifications is
something we don't agree to and will not support (or it could really
break the user interaction model of our apps)
what i was more interested was how they did the pure osd, like the
volume or brightness controls, i.e if they (mis) use the notification
protocol to do that, have another dbus interface or is the app that
actually displays the notifications that directly listens to brighness
and volume, so no protocol...
i still have to make sure by looking at the code, but from how i
understood so far is the latter approach, the brightness change is
directly monitored by the notification daemon, so nothing reusable
More information about the kde-core-devel