[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:       "Aaron Seigo" <aseigo () kde ! org>
Date:       2009-03-31 0:18:11
Message-ID: 20090331001811.24708.62211 () localhost
[Download RAW message or body]


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/472/#review745
-----------------------------------------------------------


now that i can see the patch, i can tell you that in a bit of irony, the only reason \
this won't break with autohiding panels is because we only do sliding autohide panels \
when composite is available ... because that's the only way to do them right. if we \
made a similar concession with autohide and "faked it as best we can" when composite \
isn't there, this patch wouldn't work nicely at all with hiding panels.

not that it matters, but the code doesn't follow the coding style guide (kdelibs \
style) that the rest of the code does.

- Aaron


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]