RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace
Simon Lees
simon at simotek.net
Wed Dec 23 21:44:09 UTC 2015
Sorry, I'm not on the list please CC me.
> On Thursday, December 10, 2015 2:39:36 PM CET Mark Gaiser wrote://>
> It won't depend on KWin. It will depend on an API provided by the KWayland
> library (tier 1). In runtime it depends on a wayland interface which in theory
> anybody can provide. In practice it will just be KWin.
>
>/That way other window managers could benefit from that as well. />
> Sure they can implement the interface or just use KWayland.
>
> So let's look at it again from a very technical level:
> 1. The QPT plugin currently has a de-facto not specified dependency on breeze
> 2. The QPT plugin currently has a de-facto not specified dependency on plasma-
> workspace for look-and-feel package
> 3. Right now the only package (in Debian) to depend on frameworkintegration is
> plasma-workspace
> 4. Right now users of other desktops have to manually install the package
> 5. Right now users of other desktops have to manually specify env variables
> 6. In fact we even have a non specified dependency loop as breeze depends on
> framework integration.
>
> How will this look after the logical move:
> 1. The incorrect not specified de-facto dependencies can (!) be properly
> defined as runtime dependencies
> 2. On other desktops users have to install a package which isn't automatically
> installed
> 3. On other desktops users have to manually specify env variables to use it
Please hurry up and implement this or atleast something, currently KDE5 apps
(sorry i don't know the technically correct term) are completely broken when run
under enlightenment. Most icons don't load as the fallback icon theme is hicolor
which while it contains fallback icons for applications doesn't contain a complete
icon set. So for example Dolphin out of the box on openSUSE 42.1 when run under
enlightenment or from a remote desktop session looks like the following
http://www.enlightenment.org/ss/e-567b0d4d4f1177.04759170.jpg see
https://bugzilla.suse.com/show_bug.cgi?id=920792 for more info. Then because I
prefer a dark theme as it matches enlightenment I tried using systemsetting5
to set the colorscheme as I always did for kde4 apps and I got the following.
http://www.enlightenment.org/ss/e-567b0c92d465d8.81313635.jpg
All this fallback to non kde stuff is nice, but its pretty pointless if it causes
apps not to work and people to not bother using them. I did consider exporting
KDE_SESSION_FULL=true globally but that would break xdg-utils and variety. In my
opinion you should go do your funky check for gnome stuff but if you don't find it
you should just use whatever is defined in the kde settings. Those of us who use
non GNOME / KDE environments know how to go to systemsettings5 and set up our kde
apps the way we want and to do the equivalent for gnome.
My guess is the reason you haven't heard more about this is because it effects
people who are not kde devs or part of the kde community and are unaware of the
discussions that are happening.
Cheers
Simon Lees
> What will be the actual change? A not specified dependency can be specified as
> a runtime dependency.
>
> Just by the move no dependency changes. It's a logical grouping, nothing more.
> Dependencies only change if we do specify them. By only logical moving nothing
> changes.
>
> Now yes, the move is to maybe add more dependencies in future. But this will
> happen either way or another. If we cannot depend on stuff from workspace we
> have to push them into frameworks.
>
> Please take a step back and think about the whole thing. Please think about
> whether moving a plugin in a logical structure causes the dependencies to
> increase. If you come to the conclusion that yes it will, please have a look
> at the size of the packages it would in worst case(!) start to install. Please
> compare that to the size of your hard disk. Please also compare it to other
> things like let's say LibreOffice or Chrome. Take a step back and think
> whether the change is as bad as you expect it to be or whether it's actually a
> non-issue.
>
> Cheers
> Martin
More information about the Kde-frameworks-devel
mailing list