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

[Mark Gaiser]

On Thu, Dec 10, 2015 at 10:20 AM, Martin Graesslin <mgraesslin at kde.org>
wrote:

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

Yes, it will. Here is the proof (taking archlinux as example since it is
very much like upstream with close to zero patches applied).
plasma-workspace:
https://www.archlinux.org/packages/extra/x86_64/plasma-workspace/
Depends (among others) on breeze. That in turn depends on kdecoration:
https://www.archlinux.org/packages/extra/x86_64/breeze/
plasma-workspace itself depends on kscreenlocker.
kwin is required by plasma-workspoace, but compile time only. Ok, i give
you that one.
And you're right about systemsettings. It is only required by
plasma-desktop, not workspace.


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

It's not just a barrier in my head. It's a waste of resources if one
package that doesn't need a dozen dependencies, pulls it in because someone
decided it doesn't matter for the resources. If you don't use it, don't
install it.
But that's my opinion. You know i'm all about optimization (more so then
other people) so i can understand if you don't share this opinion.

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

Poor choice in this case. I don't need to see a +1 to know you don't agree
with me. That was quite clear already.


>
> >
> > I'm against it, deal with it.
>
> I get this, but I think your refusal is based on wrong assumptions.
>

Quite possible, that's why i keep saying: "i might be wrong"...

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

There is a difference here.
As it is right now, breaking it would be a bug that has to be fixed.

When it moves to plasma workspace the breakage may be intentional for
integration purposes.

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

Could it be that "frameworkintegration" is not named properly? It sounds
like it should be "Plasma framework integration" since the examples you
give are quite specific to the needs of plasma.

To be clear, my assumption with the name "frameworkintegration" is as
follows.
I expect it to integrate framework specific features (like the file open
dialogs) as replacements of Qt features (like many of the QFileDialog
static functions that would then open framework versions of those dialogs).


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

Very valid examples!
Can't that be done in a way that doesn't make it depend on KWin? In some
abstract way?
That way other window managers could benefit from that as well.

>
> 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.
>
> Those sound like bugs that should be fixed regardless of this RFC.


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