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 > > /usr/bin/krunner > /usr/bin/plasma-desktop > /usr/bin/plasma-netbook > /usr/bin/plasma-overlay
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 templates, etc. 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 components. > 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 reasonable definition. > 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 shell. 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. cheers. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
