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

[Weng Xuetian]

Hi Mark,

Sorry to jump in the discussion. It's totally fine you found
frameworkintegration currently also useful for other desktop. But in
this specific case, if you want to achieve the same feature in some
other desktop, it would be better to make a fork of
frameworkintegration.

Currently frameworkintegration is already coupled with plasma desktop,
e.g. using kde configured icon theme, need env variable set by
startkde/startplasmacompositor to make it work, and there could be
even more in the future. And that's not a wrong thing, it is designed
to integration qt application with plasma desktop.

Making a fork and then so you can do whatever yon want. E.g. if LxQt
found kio file dialog useful, they could also keep that part of code,
and maybe read icon theme configuration from lxqt's config file
instead of kde one's.

The things you ask doesn't really need to happen under plasma's
frameworkintegration. Libraries in frameworks are more independent to
the desktop, one can make use of them to implement their own
platformtheme plugin for Qt if they found they are useful.

You probably think that Qt should split the platform theme in to many
small plugin that each one only handles a single aspect of
integration, but that's not how it works right now and probably isn't
worth the effort to do so.

Regards,
Xuetian



On Thu, Dec 10, 2015 at 5:39 AM, Mark Gaiser <markg85 at gmail.com> wrote:
>
>
> 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
>
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>