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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel