Shared OSD Service for KDE

[Aaron J. Seigo]

On May 10, 2010, Ozan Çağlayan wrote:
> I've been working to create a centralised way of rendering OSD widgets upon
> request for KDE4. Finally I wrote a KDED service which uses KOSD[0] to
> render OSD widgets.
> 
> KOSD is a small KDE application which draws nice, polished and
> plasma-themed OSD with progress bars. I decoupled the Widget class from it
> and rewrote it as a KDED service.

i think it maks a ton of sense to have this in kdebase-runtime. it would be 
nice if we could host it in kdebase-workspace so as to use things like kephal 
for the screen positioning and what not, but if apps are going to be able to 
rely on this being there (and so get away from implementing their own OSD) 
then it has to be in kdebase-runtime.

it's probably unfortunately late for 4.5, but awkwardly so: we're just hitting 
up against the feature freeze; delaying to 4.6 would mean 8-9 months before it 
is part of an SC release ... but given what is probably needed to polish this 
into the best shape possible that's probably where we're headed.

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.

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.

* 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.

*  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 :)


can't wait to see this in svn! :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100510/22950532/attachment.sig