RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

[Martin Graesslin]

On Tuesday, December 8, 2015 5:05:33 PM CET Mark Gaiser wrote:
> It's not that black and white though. There are much more desktop
> environments out there. Specifically (but not only) those that are also
> using the Qt framework, but not plasma. They would feel the change you're
> proposing, in a negative way.
> Take for instance LXQt, that would really benefit from this in their
> dialogs without dragging in plasma dependencies.

I do hope that LXQt is not setting the env variables
KDE_SESSION_FULL=true
KDE_SESSION_VERSION=5

just to get this plugin to load. This would be wrong on so many ways.

If there is interest from LXQt to use our file dialog then the solution must 
be making the file dialog available in a framework they can use in their 
plugin. But announcing that they are Plasma, no.

> Other examples are openbox where a user wants to use mostly Qt
> applications, Or tilling environments, same story. You force them to drag
> in plasma if this part moves to the workspace.

No I'm not forcing anybody. Just because that moves to Plasma doesn't mean it
* has to link other parts of Plasma
* has to be setup to depend on other parts of Plasma

and even if. Then the users will have to install a few megs of data which they 
won't use. I'm not optimizing in that area.

> 
> Right now we're in a - imho - perfectly fine situation where one can get
> all the Qt + Framework integration goodness with just setting an
> environment variable.
> I'm in favor of keeping it that way.

That doesn't change a thing! Please don't turn a move of a plugin into a 
different location into a big thing. If users doesn't want to use it anymore 
because "it's now part of plasma", well then bad luck for them.

In the past I haven't seen any problem for LXQt users to use KWin or Breeze. 
So what should that problem be with frameworkintegration???

> 
> Quote: "Please don't start about GNOME's dialog being not that good as
> ours. That's not the point."
> Really.. I did not say gnome. I said better then the stock Qt (file)
> dialogs. Stop assuming that i mean GNOME with this mail, i just don't

I took GNOME as an example. I could as well write LXQt or i3. Doesn't matter 
to me.

If other DE's want to use our file dialog it needs to be split out into a 
dedicated framework and then be used from their (!) QPT plugin.

> 
> > > I really see value in having that usable in - say - openbox or any other
> > > non plasma environment where people would want to open KDE applications
> > > that make use of framework libraries (like KIO).
> > 
> > which is still possible. They need to install the package and set the env
> > variables. That's the same as right now: they need to install the package
> > and
> > set the env variables. It's not an automagically works anyway.
> 
> Yes, but they will drag in plasma, just for that. I would not consider that
> good.

Nothing will be dragged in. One package which is then under the Plasma 
umbrella instead of framework. I just don't get your point.

And no I don't care if users have to install Plasma to use parts of Plasma.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151208/deda5c88/attachment.sig>