> 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
