using device targets in qml plasmoids

[Marco Martin]

On Wednesday 24 October 2012, Aaron J. Seigo wrote:
> hi ...
> 
> i think it is time that we started using PLASMA_CUSTOM_PREFIX_PATHS and
> KDE_PLASMA_COMPONENTS_PLATFORM. what do they do, you ask? :)

we definitely need a standard hyerarchy to have it work reliably

> the first one adds additional paths to plasmoid packages. the intended use
> is to define the current device target in a way that is largely
> transparent to the developer. if it was set to "tablet" for instance, then
> one could have:
> 
> org.kde.somePackage
> 	metadata.desktop
> 	contents/
> 		ui/
> 		config/
> 		images/
> 	tablet/
> 		ui/

the notifications plasmoids atm does that, it has:
contents/
    ui/
    ..
platformcontents/
    widget/
    	touch/
        	ui/
        	..

ie there is also a difference between being a widget in a containment and 
standalone (for instance with plasma-windowed, used in the rss one for 
instance)

> PLASMA_CUSTOM_PREFIX_PATHS allows setting a set of paths, colon separated,
> e.g.:
> 
> 	PLASMA_CUSTOM_PREFIX_PATHS=tablet:vivaldi
> 
> KDE_PLASMA_COMPONENTS_PLATFORM is similar, but it controls which components
> are used by default (e.g. touch vs desktop).
> 
> what i'd like to propose is this:
> 
> * merge PLASMA_CUSTOM_PREFIX_PATHS and KDE_PLASMA_COMPONENTS_PLATFORM; the
> first entry (if any) of PLASMA_CUSTOM_PREFIX_PATHS would become what
> KDE_PLASMA_COMPONENTS_PLATFORM is. this causes a small issue: the two are
> not 100% corelated -> PATHS should probably be tablet for a tablet, but
> the COMPONENTS should be touch; PATHS should probably be mediacenter (or
> whatever) for a mediacenter and COMPONENTS should perhaps be touch as well
> (ok, maybe not, but just for argument's sake let's pretend ;) ... a
> solution to this would be to symlink the touch components directory to a
> directory called "tablet".

i think it makes sense in theory.
basically tablet would be a sub case of touch, like
touch
    tablet
    handheld
    desktop wit touch
    ...

At least that's an interpretation.
another interpretation can be that "touch" and "tablet" are instead two 
ortogonal concepts that don't necessarily overlap

in practiche i see a bit of difficulty for components:
basically we have to have an entire installed copy of components for each 
target, so right now there is a complete set for desktop a complete set for 
touch, adding more, or subcases, like touch:tablet would make the number of 
installed files grow exponentuially


not a big problem for development because on git there are only the specific 
ones, no copies, but cmake installs the base set several times, doh

> 
> this is motivated by my experience with the SLC plasmoid on the dekstop
> where the spacing between icons is too large on the desktop, but just
> right for touch screens. :)

yep, after changing how the menu is done i wanted to fix slc for the multiple 
use cases


-- 
Marco Martin