<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 10:20 AM, Martin Graesslin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Thursday, December 10, 2015 9:54:15 AM CET Mark Gaiser wrote:<br>
> On Thu, Dec 10, 2015 at 8:07 AM, Martin Graesslin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>><br>
><br>
> wrote:<br>
> > On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:<br>
> > > On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser <<a href="mailto:markg85@gmail.com">markg85@gmail.com</a>> wrote:<br>
> > > > On Wed, Dec 9, 2015 at 8:24 AM, Martin Graesslin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>><br>
> ><br>
> > wrote:<br>
> > > >> On Tuesday, December 8, 2015 6:03:47 PM CET Mark Gaiser wrote:<br>
> > > >> > I thought the frameworkintegration plugin was exactly that and<br>
> ><br>
> > usable<br>
> ><br>
> > > >> > for<br>
> > > >> > any platform if they wish to use it.<br>
> > > >> > Or is my assumption wrong and is it really only for Plasma and<br>
> ><br>
> > should<br>
> ><br>
> > > >> > others stay away from it?<br>
> > > >><br>
> > > >> well obviously it's only for plasma as it's bound to env variables<br>
> ><br>
> > set by<br>
> ><br>
> > > >> startkde. And in 4.x time the qpt plugin was in kde-workspace repo,<br>
> ><br>
> > see:<br>
> ><br>
> ><br>
> > <a href="https://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=4f67cc55104fe1081b" rel="noreferrer" target="_blank">https://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=4f67cc55104fe1081b</a><br>
> ><br>
> > 05d381e9516e0215f8e24a&hb=1b97d4427257120e305408404bff5ec6be0b65a9&f=qgui<br>
> ><br>
> > > >> platformplugin_kde %2Fqguiplatformplugin_kde.cpp<br>
> > > >><br>
> > > >> > My assumption can very well be wrong, but then i think we need to<br>
> ><br>
> > have<br>
> ><br>
> > > >> > a<br>
> > > >> > "base" frameworkintegration that every app dev can use with or<br>
> ><br>
> > without<br>
> ><br>
> > > >> > plasma. And a plasma specific version that integrates more in<br>
> ><br>
> > plasma i<br>
> ><br>
> > > >> > suppose.<br>
> > > >><br>
> > > >> I don't think it's anything an app developer should care about. It's<br>
> > > >> integration, that's not something the app developer picks - otherwise<br>
> ><br>
> > the<br>
> ><br>
> > > >> app<br>
> > > >> breaks on integrating with other platforms.<br>
> > > >><br>
> > > >> > I don't care for that either. It's logical and to be expected.<br>
> > > >> > I do care when i want to use the KF5 filedialog and need to install<br>
> > > >> > plasma<br>
> > > >> > (which has absolutely nothing to do with the dialog) just to get<br>
> > > >> > it.<br>
> > > >> > With "use" i mean the file open dialog, not the ones you can just<br>
> ><br>
> > call<br>
> ><br>
> > > >> > from<br>
> > > >> > the C++ side of things.<br>
> > > >> ><br>
> > > >> > And i definitely do not want to make a QPA just to have that<br>
> ><br>
> > working.<br>
> ><br>
> > > >> Well you have to. The file dialog is part of integration. If you want<br>
> ><br>
> > to<br>
> ><br>
> > > >> have<br>
> > > >> a specific integration you need to provide a QPT (not QPA) plugin.<br>
> > > >> Application<br>
> > > >> developers must keep away from that.<br>
> > > >><br>
> > > >> Please also read up on the topic of why KFileDialog got removed from<br>
> ><br>
> > our<br>
> ><br>
> > > >> API.<br>
> > > >><br>
> > > >> Cheers<br>
> > > >> Martin<br>
> > > ><br>
> > > > I see what you mean, i understand your opinion, but... I just don't<br>
> ><br>
> > like<br>
> ><br>
> > > > it<br>
> > > > for all the reasons given earlier.<br>
> > > > I might be a minority here, not many people are responding besides<br>
> ><br>
> > Aleix<br>
> ><br>
> > > > and myself.<br>
> > > ><br>
> > > > Lets both take a step back and let some other opinions flow in.<br>
> > ><br>
> > > I don't really understand your points...<br>
> > ><br>
> > > LXQt/Other Desktops can depend on Plasma packages if they wish. Some<br>
> > > of them have used KWin at some point, AFAIK.<br>
> ><br>
> > +1. I also just don't get Mark's points. It sounds to me like the "oh gosh<br>
> > a<br>
> > dependency on Plasma is EVIL". If users have a problem with installing the<br>
> > dependency because it's part of Plasma and not part of Frameworks I'd say<br>
> > bad<br>
> > luck for them. We shouldn't code around barriers in people's mind.<br>
><br>
> Really, you're going to act like that?<br>
> Let me remind you that you opened an Request For Comments (RFC) and i spend<br>
> the time giving (in my opinion) constructive arguments on why i think your<br>
> proposal isn't ideal. You should be happy about that. I did exactly what<br>
> one would want when posting an RFC. I've not said a single bad word about<br>
> plasma[1] and did not do and weird assumptions. You did.<br>
> If i use openbox with frameworks i do not want all of plasma being pulled<br>
> in with all the dependencies it in turn pulls in (basically the whole<br>
> plasma desktop environment).<br>
<br>
</div></div>You get this part wrong. Sorry. Just because it moves to kde/workspace,<br>
doesn't mean that it will bring in all of Plasma. The QPT plugin will<br>
certainly not:<br>
* depend on KWin<br>
* depend on Systemsettings<br>
* depend on kscreenlocker<br>
* depend on kdecoration<br>
* etc. etc.<br>
<br>
That is why I don't get your point. It just doesn't make sense to me and it<br>
sounds being based on wrong assumptions.<br></blockquote><div><br></div><div>Yes, it will. Here is the proof (taking archlinux as example since it is very much like upstream with close to zero patches applied).</div><div>plasma-workspace: <a href="https://www.archlinux.org/packages/extra/x86_64/plasma-workspace/">https://www.archlinux.org/packages/extra/x86_64/plasma-workspace/</a></div><div>Depends (among others) on breeze. That in turn depends on kdecoration: <a href="https://www.archlinux.org/packages/extra/x86_64/breeze/">https://www.archlinux.org/packages/extra/x86_64/breeze/</a></div><div>plasma-workspace itself depends on kscreenlocker.</div><div>kwin is required by plasma-workspoace, but compile time only. Ok, i give you that one.</div><div>And you're right about systemsettings. It is only required by plasma-desktop, not workspace.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
And even if dependencies by distros would be set up that it pulls in let's say<br>
KWin. What would it change? A few files get installed, that's it. It would not<br>
have any runtime impact. That's what I meant with the barrier in people's<br>
head. You cannot install Plasma (just install, not run!) because it will taint<br>
the lightweight system. If that is not what you think, then please elaborate<br>
why moving the plugin to kde/workspace is bad from your perspective.<br></blockquote><div><br></div><div>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.</div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
><br>
> I've not been offensive or leaning towards that side, but you are leaning<br>
> very much in that direction right now.<br>
> Voting on not agreeing with me, how childish can you act.<br>
<br>
</span>That wasn't voting on my side. It was just a way to indicate that I agree.<br>
Like on Google+, you +1 a comment.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
><br>
> I'm against it, deal with it.<br>
<br>
</span>I get this, but I think your refusal is based on wrong assumptions.<br></blockquote><div><br></div><div>Quite possible, that's why i keep saying: "i might be wrong"... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> I might be very wrong, there might be very good arguments to do what you<br>
> want, but you fail to convince me of the supposed benefit.<br>
><br>
> Get some more opinions in this thread! Really! And not just of plasma<br>
> orientated folks, also framework folks!<br>
<br>
</span>That's why it's send to the frameworks mailing list. I do want the feedback!<br>
If frameworks people don't provide the feedback I need to evaluate the<br>
feedback I got and so far your feedback sounds like based on wrong assumptions<br>
to me.<br>
<span class=""><br>
> I might be the one person against it where everyone else is in favor. But<br>
> we don't know right now since only 3 people (Aleix, you and me) have<br>
> responded in here.<br>
><br>
> > > We also provide the classes to set up the QPT in our frameworks, they<br>
> > > can create their own (and probably should, if you ask me).<br>
> ><br>
> > +1. And as I said: if other desktop environments consider our file dialog<br>
> > superior, we should make sure they can use it through a framework in their<br>
> > QPT. But they should not use our QPT. If they use our QPT they will hit a<br>
> > problem somewhen in future when we change something for better integration<br>
> > with Plasma and that just doesn't work at all with $DE.<br>
><br>
> But why would you break it? I really don't see the point...<br>
<br>
</span>It would not be on purpose, obviously. It's just that it can happen, because<br>
we are not aware on how it will be used outside Plasma. And I'm sure we<br>
already did break for other environments. Let's consider for example the<br>
infinite loop if a system doesn't provide SNI and no xembed. Happened,<br>
couldn't happen on Plasma because it provides SNI.<br></blockquote><div><br></div><div>There is a difference here.</div><div>As it is right now, breaking it would be a bug that has to be fixed.</div><div><br></div><div>When it moves to plasma workspace the breakage may be intentional for integration purposes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Other examples could be integration with services provided by workspace and we<br>
just don't consider that it doesn't exist, connection to powerdevil dbus<br>
services, dependencies on KWin, etc.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>To be clear, my assumption with the name "frameworkintegration" is as follows.</div><div>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).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> Convince me of the benefit of better integration with a couple of sample<br>
> use cases.<br>
<br>
</span>All right. What I currently have in mind is making the QPT plugin depend on<br>
KWayland (currently in kde/workspace) to tell KWin to use server side<br>
decorations instead of Qt's client side decorations.<br></blockquote><div><br></div><div>Very valid examples!</div><div>Can't that be done in a way that doesn't make it depend on KWin? In some abstract way?</div><div>That way other window managers could benefit from that as well.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Even right now it has incorrect runtime dependencies on kde/workspace. The<br>
default widget style is set to breeze, the fallback is oxygen. Both are part<br>
of kde/workspace. Up until recently the same was for icons (now part of<br>
frameworks). The look'n'feel package defaults to breeze, also part of<br>
workspace.<br>
<br>
So right now the QPT plugin has incorrect dependencies to Plasma.<br>
<br></blockquote><div>Those sound like bugs that should be fixed regardless of this RFC.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Cheers<br>
<span class=""><font color="#888888">Martin</font></span></blockquote></div><br></div></div>