Shared OSD Service for KDE
ozan at pardus.org.tr
Wed May 12 12:08:37 BST 2010
11 May 2010 Salı günü (saat 02:18:54) Aaron J. Seigo şunları yazmıştı:
> on the code side of it, some thoughts:
I'm asking the following questions just for curiosity/gaining experience not
that I'm insisting on the current code seen that the proper solution is still
being discussed in this thread.
> * 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
Converting the OSD widget to Plasma::Dialog was trivial *but* even if i set
WindowStaysOnTop, the OSD still stays behind of focused windows. When this was
a QWidget it was always on top. What's the trick in here?
> * 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 :)
I couldn't find a way, an example of using scalable icons instead of png ones.
Should this be manipulated manually like appending an .svg(z) extension and
searching for an svg and fallbacking to png if not present?
BTW: How long api.kde.org will stay unreachable? That's bad :(
TUBITAK/UEKAE - Pardus Linux
More information about the kde-core-devel