'Re: Review Request: Support for transparent panel without composition'

[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:       "David Nolden" <zwabel+reviewboard () gmail ! com>
Date:       2009-03-30 8:58:13
Message-ID: 20090330085813.31878.31822 () localhost
[Download RAW message or body]

> On 2009-03-30 01:29:17, Aaron Seigo wrote:
> > an early decision was not to hack things into plasma. if someone wants \
> > translucent panels and other windows, use composition. it's the only way to do it \
> > properly. i have no interest in seeing plasma become a pile of hacks held \
> > together with chewing gum and baling wire. i left kicker's code base behind \
> > because of that "hey, look what we can do!" mentality that went into that code \
> > over the years. 
> > now, this doesn't actually work in all cases (e.g. themes with solid panels), \
> > doesn't provide real translucency (e.g. see windows between the panels and the \
> > desktop), i can only imagine how this does (or doesn't) work with hiding panels \
> > and it pollutes the libplasma API with incomprehensible and very \
> > this-hack-specific methods. 
> > i appreciate what you are trying to accomplish, but it's simply not in line with \
> > plasma's design principles.
> 
> Aaron Seigo wrote:
> i also should address this comment:
> 
> "All other major linux Desktop-Environments support transparent panels without \
> composition" 
> what other software does wrong is completely inconsequential.
> 
> these other systems took this route at the time because at the time there was no \
> compositing support in X11. and even when compositing did arrive, those code bases \
> were so old and ossified and the compositing support was so crappy that nearly \
> nobody bothered to even try taking advantage of compositing. 
> but we're not writing the desktop of 5 years ago, and we're not trying to mimic the \
> mistakes of 5 years ago, either. 
> that's why, despite everyone else having a stupid xembed based system tray, we're \
> doing something new and smarter. that's why, despite everyone else shipping plain \
> run command dialogs while people make bad clones of Quicksilver as third party \
> add-ons, we work on krunner as a default component. 
> so the "but others did it" reason is no reason at all. one needs to look at what a \
> given thing is with fresh eyes and in the context of modern systems. and i'm not \
> about to wait until we're the last ones doing it wrong to make the right decisions. \
> being the first to make those decisions is not easy, and sure, being the Nth person \
> afterwards to follow along and makes those decisions is easy. but it's a lot more \
> rewarding to be the first ones to do something better than to only chase after \
> other people's taillights once it is safe to do so. 
> David Nolden wrote:
> The problem is that you're pushing technology  at the cost of the user. For \
> perfectionists like me, who want a perfectly snappy desktop, or for people with \
> badly supported video cards, composition still isn't an option. As developer of a \
> core component of a major desktop environment, you should also have an eye at the \
> present, not _only_ ot the future! 
> About pollution of hack-specific methods: The "bool blendInterface()" function \
> seemed the cleanes solution. But this could also be solved kdebase/plasma \
> internally. 
> Apart from that, this patch adds probably about 40 LOC, of which nothing seems to \
> be an awful hack, while bringing a great advantage to really many _present_ users, \
> so please think that position over again.. I fail to see how this can bring you \
> into a maintenance nightmare.

About your technical comments:
Why should this not work with solid panels? Solid panels work just fine!
It does not provide _real_ translucency in the sense that you see windows between the \
panel and the desktop, but that feature is anyway nothing more than a "look what I \
can do" feature. I do see a problem with auto-hiding panels, since in that case it \
might happen more often that a panel is over a window, maybe the fake transparency \
should better be disabled for such a case.

- David

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

On 2009-03-30 00:54:44, David Nolden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/472/
> -----------------------------------------------------------
> 
> (Updated 2009-03-30 00:54:44)
> 
> 
> 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
> -----
> 
> trink/KDE/kdebase/workspace/plasma/containments/mid-panel/panel.cpp 940781 
> trink/KDE/kdebase/workspace/plasma/containments/panel/panel.cpp 940781 
> trink/KDE/kdebase/workspace/plasma/shells/CMakeLists.txt 940781 
> trink/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.h 940781 
> trink/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.cpp 940781 
> trink/KDE/kdebase/workspace/plasma/shells/desktop/panelview.h 940781 
> trink/KDE/kdebase/workspace/plasma/shells/desktop/panelview.cpp 940781 
> trink/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.h 940781 
> trink/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] 