Shared OSD Service for KDE
Aaron J. Seigo
aseigo at kde.org
Tue May 11 00:18:54 BST 2010
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 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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel