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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
