Re: setting default widgetStyle (and ColorScheme)
On Saturday, November 28, 2015 7:58:47 PM CET René J. V. Bertin wrote: > Olivier Goffart wrote: > > A pure KF5 appliation would anyway use the KDE platform theme plugin > > provided by KDE Frameworks. (in frameworkintegration) > > (So in other words: that code should not be executed when kde frameworks > > is > > installed, in theory) > > So... No, it doesn't. Not on OS X when using the default QPA plugin (Cocoa). > From the looks of it that one lacks support for theme plugins. Or rather, > it doesn't return the appropriate thing(s) from > QGuiApplicationPrivate::platform_integration->themeNames(). > > Now the question is, should KF5 applications be able to use the KDE platform > theme plugin provided by kf5-frameworkintegration if that framework is > installed? In my opinion: no. I even think the frameworkintegration framework should get removed from frameworks and moved into Plasma Workspace. Because that's what it is about: integrating Qt applications into plasma. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
Martin Graesslin wrote: > That is in deed a better approach. I'm still questioning whether it's the > right thing to do on OSX, but that would then be up to the OSX developers to > decide on. I'll handle that tomorrow. > But if the platformtheme plugin does get moved to Plasma I would say that it > doesn't belong there as I think Plasma should only care about targeting X11 > and Wayland. That's something the Plasma team needs to decide on, though. At I don't remember the details, but I recall a discussion (probably on KDE-Mac) a while ago about components from KDE4 that make perfect sense on OS X (in a packaging approach like MacPorts') were moved to Plasma, and how that could lead to problems. >> "Never say never" mean anything to you? > > Sure! It's not possible to exchange the Quartz compositor. This means: never. > Sorry to say, but I have been in the WM business a few years now and I know > what's possible and what isn't ;-) However Apple calls their displaying technology nowadays, the window server and any related underlying technologies are indeed conceived to be impossible to take over or replace, once launched. It is however possible to log into OS X in console mode, and from there you can launch (or ought to be able, I never tried) anything else that takes over whatever handles the user interface. This is more or less what the defunct PureDarwin and OpenDarwin projects did, or aimed to do. OS X doesn't have a window manager, it has a window server that does a lot more than managing windows in X11 style. There is no dissociation between display server, window manager, and the various layers in between, except to some extent in the names of the SDKs involved. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
Martin Graesslin wrote: > In my opinion: no. I even think the frameworkintegration framework should get > removed from frameworks and moved into Plasma Workspace. Because that's what > it is about: integrating Qt applications into plasma. I don't care where the framework is, but I do think users should have the choice of enjoying all the effort that goes into making great KDE themes/styles on platforms other than Linux (and at the same time have as close a visual experience as possible using the same applications on different platforms, if they chose so). Qt does a good job in providing an appearance that matches up with the native style, but it will always remain a compromise in cross-platform code. I cannot really speak for MS Windows but I think that's very apparent on OS X where code that lacks specific adaptations will use a single font and fontsize throughout which isn't even configurable. (Lucida Grande 13pt or even 14pt, the font used in buttons, menus and window titles, but rarely elsewhere in truly native applications.) To put it bluntly: many Qt applications that lack adaptation to OS X look-n-feel appear designed for the visually (and motor) impaired: everything's just too big and spacious. Not good and "professional looking" enough IMHO. Of course one could work on improving the native theme, but wouldn't that be easiest by writing a dedicated KDE theme? In fact, I ought to check what happens if one selects the "Macintosh (aqua)" style as KDE's widget style and then applies the font selection from the fonts kcm; maybe that'll resolve the main issue with the native style on OS X. BTW, it wasn't very complicated to get the platform theme plugin to function on OS X without introducing function loss, see the RR I filed about it. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
On Monday, November 30, 2015 11:06:57 AM CET René J. V. Bertin wrote: > Martin Graesslin wrote: > > In my opinion: no. I even think the frameworkintegration framework should > > get removed from frameworks and moved into Plasma Workspace. Because > > that's what it is about: integrating Qt applications into plasma. > > I don't care where the framework is, but I do think users should have the > choice of enjoying all the effort that goes into making great KDE > themes/styles on platforms other than Linux (and at the same time have as > close a visual experience as possible using the same applications on > different platforms, if they chose so). That's not the point! Any user can use whatever theme they want. The question is whether we should default to our Plasma defaults on non-Plasma. And the question to that can only be: NO! Given that: no, the framework integration plugin should not be used anywhere except on Plasma. > > Qt does a good job in providing an appearance that matches up with the > native style, but it will always remain a compromise in cross-platform > code. Then change the QStyle. There's an env variable to specify it. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
René J. V. Bertin wrote: > Of course one could work on improving the native theme, but wouldn't that be > easiest by writing a dedicated KDE theme? In fact, I ought to check what > happens if one selects the "Macintosh (aqua)" style as KDE's widget style and > then applies the font selection from the fonts kcm; maybe that'll resolve the > main issue with the native style on OS X. For now that appears easier said than done, but it did make me think of another argument to allow for the use of KDE themes/styles on at least OS X: OS X does not support "texted separators", which means that applications using addMenuSection will see only a separator. That's a regression which I am addressing partly in my proposed KDE-specific Qt5 port for MacPorts but I have been able to do that only for menu items in the toplevel menu bar. Using the native style one also gets native contextual menus, and those I have not been able to patch. Using a KDE style one still gets a native toplevel menu bar with its menus and menu items, but contextual menus will be created through the KDE style, and thus use the style's drawing routines. Those work as expected for all KDE styles I have tried. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
Martin Graesslin wrote: Is this going to turn into another shouting match? > That's not the point! Any user can use whatever theme they want. The question > is whether we should default to our Plasma defaults on non-Plasma. And the > question to that can only be: NO! I'm not suggesting it should be the default, unless the USER CONFIGURES IT TO BE. > Given that: no, the framework integration plugin should not be used anywhere > except on Plasma. So, yes, it should be POSSIBLE to use that plugin. What's the point in disallowing it if it only requires minimal modifications? Would there be a point in disallowing someone to run a full plasma session on a platform that allows it and that isn't Linux? I'd hope the answer to that is no, and > Then change the QStyle. There's an env variable to specify it. I already stated that that's not enough. Maybe I wasn't clear: using QT_STYLE_OVERRIDE or `-style XXX` changes the widget graphical appearance but does not apply font or palette settings. With this, you're still stuck with the fugly appearance I mentioned earlier. It is even possible that we'd be running into the same widget layout issues we've seen with the native OS X style under KDE4. R ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
On Monday, November 30, 2015 1:17:20 PM CET René J. V. Bertin wrote: > Martin Graesslin wrote: > > Is this going to turn into another shouting match? sorry what? > > > That's not the point! Any user can use whatever theme they want. The > > question is whether we should default to our Plasma defaults on > > non-Plasma. And the question to that can only be: NO! > > I'm not suggesting it should be the default, unless the USER CONFIGURES IT > TO BE. > > > Given that: no, the framework integration plugin should not be used > > anywhere except on Plasma. > > So, yes, it should be POSSIBLE to use that plugin. What's the point in > disallowing it if it only requires minimal modifications? what you put on review board is in my opinion not a minimal modification. That are lots of ifdefs and each ifdef is a huge burden for the framework. It means platform specific changes which cannot be tested properly. Each of these changes make it more difficult for every other developer to work on that code base. Given that: we need to be extremely careful when we consider adding platform specific code and need to evaluate very careful the advantages for it. > > Would there be a point in disallowing someone to run a full plasma session > on a platform that allows it and that isn't Linux? It's impossible to run a full plasma session on a platform that isn't Linux or an X11/Wayland Unix. This is not something which in theory could be possible. No it's not! No matter how much work is put into porting: it's impossible to port Plasma to non Linux or an X11/Wayland Unix. So there is no point discussing that. It will never be possible to use Plasma on OSX or Windows as it's at least not possible to port KWin to these platforms. > I'd hope the answer to that is no, and > > > Then change the QStyle. There's an env variable to specify it. > > I already stated that that's not enough. Maybe I wasn't clear: using > QT_STYLE_OVERRIDE or `-style XXX` changes the widget graphical appearance > but does not apply font or palette settings. I don't think we should add the ifdefs you proposed in the review request because you don't like OSX default settings. We need to look a little bit further than what our personal preferences are when we want to do changes which affect all developers. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
On Monday, November 30, 2015 3:01:40 PM CET René J. V. Bertin wrote: > Martin Graesslin wrote: > > what you put on review board is in my opinion not a minimal modification. > > That are lots of ifdefs and each ifdef is a huge burden for the > > framework. It means > ... > > > Given that: we need to be extremely careful when we consider adding > > platform specific code and need to evaluate very careful the advantages > > for it. > I won't argue that, and I'll repeat that I have no issues splicing the code > into a few dedicated files, moving the "ifdefs" to the CMake file. > It's what I ended up doing with the changes required for kdeinit5, but that > concerned a lot more ifdefs. > > That'd put the maintenance burden on people who care about the code and the > platform on which it's supposed to function. That is in deed a better approach. I'm still questioning whether it's the right thing to do on OSX, but that would then be up to the OSX developers to decide on. But if the platformtheme plugin does get moved to Plasma I would say that it doesn't belong there as I think Plasma should only care about targeting X11 and Wayland. That's something the Plasma team needs to decide on, though. At the moment we (to my knowledge) don't have a restriction on that. Only KWin specifies itself to only target xorg windowing systems (that is X11 and Wayland). > > >> Would there be a point in disallowing someone to run a full plasma > >> session > >> on a platform that allows it and that isn't Linux? > > ... > > > So there is no point discussing that. It will never be possible to use > > Plasma on OSX or Windows as it's at least not possible to port KWin to > > these platforms. > > "Never say never" mean anything to you? Sure! It's not possible to exchange the Quartz compositor. This means: never. Sorry to say, but I have been in the WM business a few years now and I know what's possible and what isn't ;-) And that doesn't restrict to OSX. It's also not possible to get Plasma on GNOME Shell or Plasma on Unity for pretty much the same reason: it's impossible to exchange the window manager. > > Regardless, my remark was a purely rhetorical question (OS X is indeed not a > platform that currently allows to run a full Plasma session without severe > hacking). With all due respect, your reaction sadly supports an impression > I have been getting that I probably best leave unvoiced publicly... Better state clearly what you mean instead of hinting things. > > So KF5/Plasma removed the possibility to use a window manager that's not > KWin? No. But Plasma is a coherent product consisting of well integrated components. If you talk about Plasma as a product it includes KWin as the window manager. If you remove KWin as the window manager, you might be using plasmashell, but that's not Plasma anymore in my book (and probably also for all other Plasma devs). > > I don't think we should add the ifdefs you proposed in the review request > > because you don't like OSX default settings. We need to look a little bit > > It's not just I, and it's about just as much to do with the general > princpiple of allowing user choice (something *I* am -almost- religious > about) and not introducing regressions w.r.t. KDE4 . Honestly: if the "allow user choice" means introducing ifdefs, then I don't care about it. Everybody is free to have all the choice they want, but don't make your wish for user choice cost for others. That's similar to running Plasma without KWin: yes it's possible, but don't expect us Plasma devs to spend time to fix issues you get when not using KWin. You have the freedom of choice, but don't expect that anybody else cares about that ;-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
On Saturday, November 28, 2015 7:58:47 PM CET René J. V. Bertin wrote: > Olivier Goffart wrote: > > A pure KF5 appliation would anyway use the KDE platform theme plugin > > provided by KDE Frameworks. (in frameworkintegration) > > (So in other words: that code should not be executed when kde frameworks > > is > > installed, in theory) > > So... No, it doesn't. Not on OS X when using the default QPA plugin (Cocoa). > From the looks of it that one lacks support for theme plugins. Or rather, > it doesn't return the appropriate thing(s) from > QGuiApplicationPrivate::platform_integration->themeNames(). > > Now the question is, should KF5 applications be able to use the KDE platform > theme plugin provided by kf5-frameworkintegration if that framework is > installed? In my opinion: no. I even think the frameworkintegration framework should get removed from frameworks and moved into Plasma Workspace. Because that's what it is about: integrating Qt applications into plasma. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
Olivier Goffart wrote:
>
> A pure KF5 appliation would anyway use the KDE platform theme plugin provided
> by KDE Frameworks. (in frameworkintegration)
> (So in other words: that code should not be executed when kde frameworks is
> installed, in theory)
So... No, it doesn't. Not on OS X when using the default QPA plugin (Cocoa).
From the looks of it that one lacks support for theme plugins. Or rather, it
doesn't return the appropriate thing(s) from
QGuiApplicationPrivate::platform_integration->themeNames().
Now the question is, should KF5 applications be able to use the KDE platform
theme plugin provided by kf5-frameworkintegration if that framework is
installed? If that is the case, there's what I'd consider a bug in Qt.
I do have a question in this context: is there a way to determine the platform
theme that's being used, at runtime? The Cocoa QPA provides certain features
like using a menu "under" an application's Dock icon which only work with the
Cocoa ("aqua") platform plugin; the methods in the Cocoa QPA should thus check
if that's the active platform plugin to avoid crashing (if a simple nullptr
check doesn't suffice).
R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
Digging through Qt's source code to figure out if and how I can get KF5
applications to honour theming settings on OS X, I observe the following in
class QKdeThemePrivate in qgenericunixthemes.cpp:
static QString kdeGlobals(const QString )
{
return kdeDir + QStringLiteral("/share/config/kdeglobals");
}
and QVariant QKdeThemePrivate::readKdeSetting() then does
foreach (const QString , kdeDirs) {
QSettings *settings = kdeSettings.value(kdeDir);
if (!settings) {
const QString kdeGlobalsPath = kdeGlobals(kdeDir);
if (QFileInfo(kdeGlobalsPath).isReadable()) {
// ... etc ...
It may be intentional that that file avoids the use of QStandardPaths (is it?),
but it seems that this code cannot read the kdeglobals file in its intended
location (~/.config/kdeglobals on XDG-compliant systems). Not even when $KDExxx
variables are set to provide the correct value for `kdeDirs` .
Am I right that kdeGlobals() should return the current value only if
kdeVersion<=4, and for kdeVersion>=5 it should rather return `kdeDir +
QStringLiteral("/kdeglobals")`, with `kdeDirs` extended to include ~/.config?
In that case, should a fallback for "/share/config/kdeglobals" be added?
A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct?
R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: setting default widgetStyle (and ColorScheme)
On Friday November 27 2015 22:31:09 René J.V. Bertin wrote: Further observation: my font selection is also affected. The only way to get "my" widget style, fonts and colours by default is by using the Qt's Xcb plugin (unsupported, but currently it still builds) and setting KDE_FULL_SESSION=true and KDE_SESSION_VERSION=4 . All I can wonder is "why" and "WTH" ... R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
