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

Mark Gaiser markg85 at gmail.com
Thu Dec 10 08:54:15 UTC 2015


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

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.

I'm against it, deal with it.
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!
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...
Convince me of the benefit of better integration with a couple of sample
use cases.


>
> Cheers
> Martin
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
[1] .. but i can start doing that if you want, no problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151210/2b603f60/attachment.html>


More information about the Kde-frameworks-devel mailing list