[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request: Support for transparent panel without composition
From: "Rob Scheepmaker" <r.scheepmaker () student ! utwente ! nl>
Date: 2009-03-31 10:39:57
Message-ID: 20090331103957.5754.89629 () localhost
[Download RAW message or body]
> On 2009-03-30 17:32:34, Aaron Seigo wrote:
> > so .. on a purely technical level .. the invokeMethod is really ugly (though probably \
> > mildly less ugly than stuffing the API in libplasma), and will of course not work with \
> > other Containment::PanelContainment type Containments unless they duplicate the code. and \
> > there's really no way of not duplicating the code in each PanelContainment to guarantee \
> > perfect results.
> > for wallpapers that animate (e.g. the slideshow) this would cause full panel repaints \
> > during animation, over and over, with the rather more expensive SourceUnder compositing. \
> > this would likely destroy performance both for the animation and the rest of plasma on \
> > machines that already are struggling to provide service w/out compositing and/or OpenGL \
> > available to them.
> > grabWidget causes a full repaint, which would be even more expensive (so we're talking \
> > about a paint on the desktop causing a repaint in the panel and another repaint in the \
> > desktop); grabWindow would just grab the relevant bits but likely has its own problems?
> > there's also future proofing concerns there with multiple overlapping panels and \
> > per-desktop panels.
> > i hope this all helps to explain why it's simply not an option.
>
> David Nolden wrote:
> - I know invokeMethod is ugly, that's why there was the public interface before..
> - About the updating: Yes of course, but isn't it the same with plasmoids?
> - The gab(..) calls are restricted to the area under the panel, which usually only contains a \
> part of the wallpaper, so we're mainly talking about blitting here
> Actually, I don't need this feature in this incarnation, and would consider allowing to \
> setting a configurable rendering background for transparent panels, extenders, etc. much more \
> useful, since it would solve the problem not only for the panels. If the user would set the \
> background to the same as the wallpaper, he would have a transparency-like effect without a \
> hack.
That sounds like a very sensible approach: nicer looking translucent themes without one hell of \
a hack. I'd say go for it!
- Rob
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/472/#review746
-----------------------------------------------------------
On 2009-03-30 06:37:48, David Nolden wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/472/
> -----------------------------------------------------------
>
> (Updated 2009-03-30 06:37:48)
>
>
> Review request for Plasma.
>
>
> Summary
> -------
>
> Many people can not, or do not want to use composition. A semi-transparent panel highly \
> increases the appeal of a Desktop, and there currently is only very few plasma themes \
> available that have a nice-looking panel without transparency enabled.
> All other major linux Desktop-Environments support transparent panels without composition(KDE \
> 3.x, GNOME, and others), and since usually the only thing that needs to be visible through \
> the panel is the Desktop itself, using a composition-less approach does not have much \
> disadvantage here.
> Here's I'm proposing a patch to achieve this in a relatively clean way: The panel is painted \
> and updated as if it was a plasmoid on the Desktop itself, grabbing the painted area \
> plasma-internally directly from the underlying desktop-view. The corresponding area of the \
> panel is updated whenever the desktop is repainted, which means that animated plasmoids \
> partially hidden under the panel, animations like the desktop-fading, moving plasmoids \
> partially under the panel, etc. "just work".
> Result: A nice looking panel for everyone, less work for theme designers. Please don't leave \
> those behind who don't want or can not use desktop composition!
> (Note: If you try this out, it doesn't work with all themes, since some themes seem to have \
> no alpha-information in the non-composition case).
>
> Diffs
> -----
>
> trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.h 940781
> trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.cpp 940781
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.h 940781
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.cpp 940781
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.h 940781
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.cpp 940781
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.h 940781
> trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.cpp 940781
>
> Diff: http://reviewboard.kde.org/r/472/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> David
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic