<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 8, 2015 at 5:27 PM, 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"><span class="">On Tuesday, December 8, 2015 5:05:33 PM CET Mark Gaiser wrote:<br>
> It's not that black and white though. There are much more desktop<br>
> environments out there. Specifically (but not only) those that are also<br>
> using the Qt framework, but not plasma. They would feel the change you're<br>
> proposing, in a negative way.<br>
> Take for instance LXQt, that would really benefit from this in their<br>
> dialogs without dragging in plasma dependencies.<br>
<br>
</span>I do hope that LXQt is not setting the env variables<br>
KDE_SESSION_FULL=true<br>
KDE_SESSION_VERSION=5<br>
<br>
just to get this plugin to load. This would be wrong on so many ways.<br>
<br>
If there is interest from LXQt to use our file dialog then the solution must<br>
be making the file dialog available in a framework they can use in their<br>
plugin. But announcing that they are Plasma, no.<br>
<span class=""><br>
> Other examples are openbox where a user wants to use mostly Qt<br>
> applications, Or tilling environments, same story. You force them to drag<br>
> in plasma if this part moves to the workspace.<br>
<br>
</span>No I'm not forcing anybody. Just because that moves to Plasma doesn't mean it<br>
* has to link other parts of Plasma<br>
* has to be setup to depend on other parts of Plasma<br>
<br>
and even if. Then the users will have to install a few megs of data which they<br>
won't use. I'm not optimizing in that area.<br>
<span class=""><br>
><br>
> Right now we're in a - imho - perfectly fine situation where one can get<br>
> all the Qt + Framework integration goodness with just setting an<br>
> environment variable.<br>
> I'm in favor of keeping it that way.<br>
<br>
</span>That doesn't change a thing! Please don't turn a move of a plugin into a<br>
different location into a big thing. If users doesn't want to use it anymore<br>
because "it's now part of plasma", well then bad luck for them.<br>
<br>
In the past I haven't seen any problem for LXQt users to use KWin or Breeze.<br>
So what should that problem be with frameworkintegration???<br>
<span class=""><br>
><br>
> Quote: "Please don't start about GNOME's dialog being not that good as<br>
> ours. That's not the point."<br>
> Really.. I did not say gnome. I said better then the stock Qt (file)<br>
> dialogs. Stop assuming that i mean GNOME with this mail, i just don't<br>
<br>
</span>I took GNOME as an example. I could as well write LXQt or i3. Doesn't matter<br>
to me.<br>
<br>
If other DE's want to use our file dialog it needs to be split out into a<br>
dedicated framework and then be used from their (!) QPT plugin.<br></blockquote><div><br></div><div>I thought the frameworkintegration plugin was exactly that and usable for any platform if they wish to use it.</div><div>Or is my assumption wrong and is it really only for Plasma and should others stay away from it?<br></div><div><br></div><div>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.</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 really see value in having that usable in - say - openbox or any other<br>
> > > non plasma environment where people would want to open KDE applications<br>
> > > that make use of framework libraries (like KIO).<br>
> ><br>
> > which is still possible. They need to install the package and set the env<br>
> > variables. That's the same as right now: they need to install the package<br>
> > and<br>
> > set the env variables. It's not an automagically works anyway.<br>
><br>
> Yes, but they will drag in plasma, just for that. I would not consider that<br>
> good.<br>
<br>
</span>Nothing will be dragged in. One package which is then under the Plasma<br>
umbrella instead of framework. I just don't get your point.<br>
<br>
And no I don't care if users have to install Plasma to use parts of Plasma.<br></blockquote><div><br></div><div>I don't care for that either. It's logical and to be expected.</div><div>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.</div><div>With "use" i mean the file open dialog, not the ones you can just call from the C++ side of things.<br></div><div><br></div><div>And i definitely do not want to make a QPA just to have that working. <br></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>
Cheers<br>
<span class=""><font color="#888888">Martin</font></span></blockquote></div><br></div></div>