plasma and new shadow mess
Aaron J. Seigo
aseigo at kde.org
Mon Jan 7 19:17:38 GMT 2013
On Monday, January 7, 2013 15:15:21 Thomas Lübking wrote:
> On Montag, 7. Januar 2013 10:51:11 CEST, Aaron J. Seigo wrote:
> > it is a library. that does not rely on the desktop (or other) shell. it
> > provides shared functionality for applications in kde-workspace, but
> > without a guaranteed API for others (ergo no headers).
> $ for name in /usr/bin/*; do if [ ! -z "`ldd "$name" | grep
> libplasmagenericshell`" ]; then echo "$name"; fi; done
so far so good ... these 4 processes use the library. the library has no
dependencies on them.
> So it provides panelshadows, a widgetexplorer, a "Click to change how an
> action is triggered" mouseinputbutton, a wallpaperpreview, a
> backgrounddialog (seems wallpaper picker) ...
it also includes the desktop js scripting used for layouts, activity
so yes, it's really a grab bag of "things used in common by the workspace
apps". as an internal library, such "design-less" factor-out-common-stuff
pragmatism is fine.
as an aside: during the move to libplasma2 + qml2, at least some of these
things (perhaps the majority, even) will likely become individual QML
> plasma-* are thin wrappers on the libs that effectively form the desktop
plasma-desktop is over 2x the lines of code of libplasmagenericshell. it
extends classes from the libraries, even. so it is not a thin wrapper by any
> links "libplasmagenericshell.so" it is even *semantically* the gnome/unity
> approach - or i need a new dictionary.
i don't think you need a new dictionary. but digging a bit deeper into the
facts and actually understanding the design of the software you are writing
about would be useful.
in this case, the library is not where the core code, or even the semantic
definition, of the shell processes resides. in fact, the bits that make them
shells (the panels, the desktop views, screen handling, configuration, etc..)
are predominantly in the shell processes. using libplasmagenericshell does not
somehow integrate it more (or less) with Plasma Desktop or any other plasma
this is all a moot discussion, however, and i engage only to help you
understand something better which you evidently have misconceptions about.
the actual solution, however, is not dependent on getting this particular
aspect right. if we focus on solution instead of pointless discussion we
probably come to this:
if libplasmagenericshell is too big of a library or contains functionality
kwin is allergic to (for whatever reason one finds/invents), the obvious answer
is to move the shadow classes to one of the smaller kde-workspace libraries
kwin already links to such as libkworkspace, which the shells also already
link to. as they are internal libraries shipped with the binaries, such a
shuffle is easy to do and completely allowed, even between minor releases.
in fact, the *best* answer would probably be to copy the DialogShadows class
from kdelibs/plasma/private/ and put it in kworkspace (or wherever we figure is
appropriate so as to meet the needs of kwin and the other binaries in kde-
workspace). it is an improvement over the PanelShadows, which assumes the
window is edge docked and shadows can therefore be applied all the way around
without regard for the reality of the window's borders.
"porting" the use in plasma-desktop to this replacement class is trivial: it's
the same API except addWindow has one more parameter, the default argument of
which would be equivalent to the existing PanelShadows behaviour. so .. no
porting other than perhaps changing the name of the class used.
if this is a fitting / desired solution, i can easily make it happen in a very
short time span.
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel