plasma and new shadow mess

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130107/597ab90a/attachment.sig>