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

[Mark Gaiser]

On Tue, Dec 8, 2015 at 5:27 PM, Martin Graesslin <mgraesslin at kde.org> wrote:

> 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 thought the frameworkintegration plugin was exactly that and usable for
any platform if they wish to use it.
Or is my assumption wrong and is it really only for Plasma and should
others stay away from it?

My assumption can very well be wrong, but then i think we need to have a
"base" frameworkintegration that every app dev can use with or without
plasma. And a plasma specific version that integrates more in plasma i
suppose.


>
> >
> > > > 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.
>

I don't care for that either. It's logical and to be expected.
I do care when i want to use the KF5 filedialog and need to install plasma
(which has absolutely nothing to do with the dialog) just to get it.
With "use" i mean the file open dialog, not the ones you can just call from
the C++ side of things.

And i definitely do not want to make a QPA just to have that working.


> Cheers
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151208/6f819373/attachment-0001.html>