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

[Mark Gaiser]

On Tue, Dec 8, 2015 at 7:49 AM, Martin Graesslin <mgraesslin at kde.org> wrote:

> On Monday, December 7, 2015 3:54:31 PM CET Mark Gaiser wrote:
> > While at it. Why does frameworkintegration force [1] specific fonts upon
> > the user?
> >
> > It's fine that apparently some folks prefer Oxygen fonts over all else,
> but
> > i thoroughly dislike it.
> > I always end up blacklisting it in my pacman manager (pacman, archlinux)
> > since 99% of the time when i have font issues, it's because of that
> package
> > being installed.
>
> We cannot find a font which makes everybody happy. This is impossible, so
> please let's not derail the discussion.
>

Ok.

> >
> > Regarding your proposal. When running KDE apps on something other then
> > Plasma, you would also want to have the frameworksintegration plugin to
> be
> > loaded, right?
>
> No. As I outlined, it would not get loaded as the required env variables
> are
> set by startkde. I doubt that GNOME is announcing the KDE_SESSION_VERSION
> env
> variable.
>

I did not mention gnome. I don't mean any particular desktop environment,
just others in general.

>
> > Specially the platformtheme folder with the vastly improved dialogs over
> > stock Qt. Remember, those improved dialogs have the power of KIO behind
> it
> > instead of the default Qt support (only the local filesystem)
>
> On other desktop environments it should pick the platform's native dialog.
> E.g. on GNOME we want to give users the GNOME's file dialog to have an
> integrated experience. Please don't start about GNOME's dialog being not
> that
> good as ours. That's not the point. We want GTK applications to pick our
> file
> dialog in Plasma and we want our application's to pick GNOME's file dialog
> in
> GNOME. Our subjective feeling of superior user experience is pointless if
> the
> user is used to the platform's file dialog.
>

You're right and wrong.
In a Plasma VS GNOME world where either one will be used as the users
desktop environment, you're right.

It's not that black and white though. There are much more desktop
environments out there. Specifically (but not only) those that are also
using the Qt framework, but not plasma. They would feel the change you're
proposing, in a negative way.
Take for instance LXQt, that would really benefit from this in their
dialogs without dragging in plasma dependencies.
Other examples are openbox where a user wants to use mostly Qt
applications, Or tilling environments, same story. You force them to drag
in plasma if this part moves to the workspace.

Right now we're in a - imho - perfectly fine situation where one can get
all the Qt + Framework integration goodness with just setting an
environment variable.
I'm in favor of keeping it that way.

Quote: "Please don't start about GNOME's dialog being not that good as
ours. That's not the point."
Really.. I did not say gnome. I said better then the stock Qt (file)
dialogs. Stop assuming that i mean GNOME with this mail, i just don't


>
> >
> > I really see value in having that usable in - say - openbox or any other
> > non plasma environment where people would want to open KDE applications
> > that make use of framework libraries (like KIO).
>
> which is still possible. They need to install the package and set the env
> variables. That's the same as right now: they need to install the package
> and
> set the env variables. It's not an automagically works anyway.
>

Yes, but they will drag in plasma, just for that. I would not consider that
good.

>
> >
> > Isn't the only plasma specific part the KStyle folder?
>
> No.
>
> Cheers
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151208/4c895700/attachment.html>