> 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

Reply via email to