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

[Martin Graesslin]

On Thursday, December 10, 2015 9:54:15 AM CET Mark Gaiser wrote:
> On Thu, Dec 10, 2015 at 8:07 AM, Martin Graesslin <mgraesslin at kde.org>
> 
> wrote:
> > On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:
> > > On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser <markg85 at gmail.com> wrote:
> > > > On Wed, Dec 9, 2015 at 8:24 AM, Martin Graesslin <mgraesslin at kde.org>
> > 
> > wrote:
> > > >> On Tuesday, December 8, 2015 6:03:47 PM CET Mark Gaiser wrote:
> > > >> > 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?
> > > >> 
> > > >> well obviously it's only for plasma as it's bound to env variables
> > 
> > set by
> > 
> > > >> startkde. And in 4.x time the qpt plugin was in kde-workspace repo,
> > 
> > see:
> > 
> > 
> > https://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=4f67cc55104fe1081b
> > 
> > 05d381e9516e0215f8e24a&hb=1b97d4427257120e305408404bff5ec6be0b65a9&f=qgui
> > 
> > > >> platformplugin_kde %2Fqguiplatformplugin_kde.cpp
> > > >> 
> > > >> > 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 don't think it's anything an app developer should care about. It's
> > > >> integration, that's not something the app developer picks - otherwise
> > 
> > the
> > 
> > > >> app
> > > >> breaks on integrating with other platforms.
> > > >> 
> > > >> > 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.
> > 
> > > >> Well you have to. The file dialog is part of integration. If you want
> > 
> > to
> > 
> > > >> have
> > > >> a specific integration you need to provide a QPT (not QPA) plugin.
> > > >> Application
> > > >> developers must keep away from that.
> > > >> 
> > > >> Please also read up on the topic of why KFileDialog got removed from
> > 
> > our
> > 
> > > >> API.
> > > >> 
> > > >> Cheers
> > > >> Martin
> > > > 
> > > > I see what you mean, i understand your opinion, but... I just don't
> > 
> > like
> > 
> > > > it
> > > > for all the reasons given earlier.
> > > > I might be a minority here, not many people are responding besides
> > 
> > Aleix
> > 
> > > > and myself.
> > > > 
> > > > Lets both take a step back and let some other opinions flow in.
> > > 
> > > I don't really understand your points...
> > > 
> > > LXQt/Other Desktops can depend on Plasma packages if they wish. Some
> > > of them have used KWin at some point, AFAIK.
> > 
> > +1. I also just don't get Mark's points. It sounds to me like the "oh gosh
> > a
> > dependency on Plasma is EVIL". If users have a problem with installing the
> > dependency because it's part of Plasma and not part of Frameworks I'd say
> > bad
> > luck for them. We shouldn't code around barriers in people's mind.
> 
> Really, you're going to act like that?
> Let me remind you that you opened an Request For Comments (RFC) and i spend
> the time giving (in my opinion) constructive arguments on why i think your
> proposal isn't ideal. You should be happy about that. I did exactly what
> one would want when posting an RFC. I've not said a single bad word about
> plasma[1] and did not do and weird assumptions. You did.
> If i use openbox with frameworks i do not want all of plasma being pulled
> in with all the dependencies it in turn pulls in (basically the whole
> plasma desktop environment).

You get this part wrong. Sorry. Just because it moves to kde/workspace, 
doesn't mean that it will bring in all of Plasma. The QPT plugin will 
certainly not:
* depend on KWin
* depend on Systemsettings
* depend on kscreenlocker
* depend on kdecoration
* etc. etc.

That is why I don't get your point. It just doesn't make sense to me and it 
sounds being based on wrong assumptions.

And even if dependencies by distros would be set up that it pulls in let's say 
KWin. What would it change? A few files get installed, that's it. It would not 
have any runtime impact. That's what I meant with the barrier in people's 
head. You cannot install Plasma (just install, not run!) because it will taint 
the lightweight system. If that is not what you think, then please elaborate 
why moving the plugin to kde/workspace is bad from your perspective.

> 
> I've not been offensive or leaning towards that side, but you are leaning
> very much in that direction right now.
> Voting on not agreeing with me, how childish can you act.

That wasn't voting on my side. It was just a way to indicate that I agree.  
Like on Google+, you +1 a comment.

> 
> I'm against it, deal with it.

I get this, but I think your refusal is based on wrong assumptions.

> I might be very wrong, there might be very good arguments to do what you
> want, but you fail to convince me of the supposed benefit.
> 
> Get some more opinions in this thread! Really! And not just of plasma
> orientated folks, also framework folks!

That's why it's send to the frameworks mailing list. I do want the feedback! 
If frameworks people don't provide the feedback I need to evaluate the 
feedback I got and so far your feedback sounds like based on wrong assumptions 
to me.

> I might be the one person against it where everyone else is in favor. But
> we don't know right now since only 3 people (Aleix, you and me) have
> responded in here.
> 
> > > We also provide the classes to set up the QPT in our frameworks, they
> > > can create their own (and probably should, if you ask me).
> > 
> > +1. And as I said: if other desktop environments consider our file dialog
> > superior, we should make sure they can use it through a framework in their
> > QPT. But they should not use our QPT. If they use our QPT they will hit a
> > problem somewhen in future when we change something for better integration
> > with Plasma and that just doesn't work at all with $DE.
> 
> But why would you break it? I really don't see the point...

It would not be on purpose, obviously. It's just that it can happen, because 
we are not aware on how it will be used outside Plasma. And I'm sure we 
already did break for other environments. Let's consider for example the 
infinite loop if a system doesn't provide SNI and no xembed. Happened, 
couldn't happen on Plasma because it provides SNI.

Other examples could be integration with services provided by workspace and we 
just don't consider that it doesn't exist, connection to powerdevil dbus 
services, dependencies on KWin, etc.

> Convince me of the benefit of better integration with a couple of sample
> use cases.

All right. What I currently have in mind is making the QPT plugin depend on 
KWayland (currently in kde/workspace) to tell KWin to use server side 
decorations instead of Qt's client side decorations.

Even right now it has incorrect runtime dependencies on kde/workspace. The 
default widget style is set to breeze, the fallback is oxygen. Both are part 
of kde/workspace. Up until recently the same was for icons (now part of 
frameworks). The look'n'feel package defaults to breeze, also part of 
workspace.

So right now the QPT plugin has incorrect dependencies to 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/20151210/9abc1fb7/attachment-0001.sig>