Shared OSD Service for KDE

[Marco Martin]

On Tuesday 11 May 2010, Aaron J. Seigo wrote:

> 
> it would be nice to have a class in kdelibs that hides the "implementation
> details" of how the OSD is called as well, so apps don't have to mess with
> the dbus call itself. in fact, that OSD could even do something along the
> lines of show a simple OSD on screen if the dbus service isn't there. that
> would actually allow us to move the OSD implementation into
> kdebase-workspace. such a class would also allow us to eventually propose
> the d-bus spec ast fd.o and if accepted (which would mean changing from an
> org.kde dbus service to an org.freedesktop one), then the KDE apps using
> the OSD via suc ha class wouldn't require any modifications and would
> continue to Just Work.

yes, i would really like something like the notifications or 
statusnotifieritem: a simple class in kdeui that doesn't depend from anything 
except dbus that controls the kdebase-runtime daemon
heck it could even have a rather ugly kpassivepopup-style fallback if the dbus 
interface is not registered (and that would allow the daemon bein in 
workspace)

> on the code side of it, some thoughts:
> 
> * in the KDE Workspace projects we made a decision not to implement fake
> translucency hacks. they don't look very good when there is moving /
> changing content beneath them and just add overhead and more code to
> maintain for something that has a proper solution (compositing). it would
> be good if that was kept consistent, otherwise we'll get (poor looking)
> fake-translucency in one component but not others. as a bonus, it would
> also get rid of the setOpacity call on the painter, which ends up
> triggering a rather slow path in Qt. it would also mean being able to get
> rid of setOpacity.
> 
> * i'd recommend using Plasma::Dialog instead of a QWidget with its own
> painting. it will avoid duplicating painting and management code and will
> get features "for free" as they come on-line, such as the blur-behind
> effect
> 
> * KOSD::showOSD(QString icon, QString label, int percent) should probably
> be KOSD::showOSD(const QString &icon, const QString &label, int percent)
> 
> * following our naming schemes, this should probably be showOsd, KOsd, etc?
> 
> * why does OSD::updateLayout manually position everything instead of using
> a layout? even the meter.patch doesn't use a Qt layout?
> 
> * it would be really nice to have some "preset" kinds of OSD displays.
> perhaps KOsd could export a set of methods such as showAudioVolumeOsd,
> showScreenBrightnessOsd or provide a different method that takes the kind
> as the first parameter, e.g. "showStandardOsd(const QString &type, ..)".
> personally i lean to show<Type>Osd() methods since they could be augmented
> with type specific parameters; e.g. the audio OSD could take a channel /
> device name as a parameter and optionally display that in a predefine
> label. having such standardized OSDs for common usages will allow us to
> decide which icons to use, layouts, etc.
> 
> 
> art direction issues:
> 
> *  it would be really nice to have an "OSD effect" in kwin that would fade
> the osd in/out. the OSD window would mark itself with the right atom and
> kwin would do the rest.

and, like other things should be in plasma, the OSD window type, so kwin would 
also know to do all the right things at once, like skipping taskbar, not 
giving focus etc.

> * we may want a different background for the OSD than for other workspace
> elements (the standard dialog background may be too "bright". if it comes
> to that we can easily add a setBackgroundSvg(const QString &svg) method to
> Plasma::Dialog for this purpose.

will there ever be text? it's pretty much the discriminating factor that 
decides if we can use a really light background or it has to be like 
everything else.

> *  the standardized displays really ought to use icons that match with the
> style we use in the system tray. in fact, the audio display probably should
> use the audio icon SVG we are using for consistency. one more reason to opt
> for the standardized OSD methods :)

yes, i did change the own kmix one and is looking way nicer, probably, exactly 
as the statusnotifier spec, it should specify an icon name, then the 
visualization decides if use the icon from the icon theme or the plasma theme


Cheers,
Marco Martin