-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126198/#review89008
-----------------------------------------------------------


A couple of things I jotted down today, probably open doors but nonetheless 
maybe something to consider and take into account for those who have little or 
no first-hand experience with Qt on OS X or even MS Windows.

On Linux and other Unices that aren't OS X/iOS, there is no native platform SDK 
that provides predefined generic (and less generic) buttons, menus and whatever 
widgets. If we ignore Wayland, there was only X11, which simply provides 
windows, undecorated and empty bits of screen space that aren't even 
necessarily rectangular. What you do with those windows is completely up to 
you. And that's exactly what Qt did when they designed the Fusion theme that 
was introduced in Qt5.
Qt applications that are started on a Linux system and that don't have access 
to anything else, will by default use the QGenericUnixTheme, combined with 
Fusion. Given that this was designed from scratch, it is not surprising that 
its use gives interfaces designed with the generic Qt toolbox a pretty damn 
good look, leading to interfaces that are perfectly workable and maybe even 
enjoyable to use. They even don't look too much out of place on other 
platforms, because that was another design criterium from what I understand.

OS X and MS Windows on the other hand do provide their own SDKs with predefined 
generic (and less generic) buttons, menus and whatever widgets. Cross-platform 
middlewares like Qt can indeed be expected to use those SDKs as the basis for 
their platform implementation (which doesn't mean they should be forbidden from 
also providing a true cross-platform-coherent look). But such a middleware can 
only guarantee to provide generic controls that map to the generic native 
widgets, or else at most a smallest common denominator collection of more 
specialised widgets that exist in the SDKs of all supported platforms.
As a result, interfaces built with only that cross-platform toolbox will look 
more or less good depending on how well generic design principles that come 
with using Qt map to the underlying toolkits --- and influenced by Tufte as I 
am, I firmly believe that this can and will have implications for interface 
usability.

To borrow a metaphor and proverb: a generic, "bare-bones" Qt interface using 
the OS X native theme will look like it's wearing the emperor's clothes, but 
clearly wasn't designed for wearing those clothes. The extent to which this is 
the case varies from application to application, but you can (and likely will) 
end up with cases where the native theme makes an application look more out of 
place than a theme like Fusion (if it could be used in its full form).

This was particularly visible in KDE4 applications using the native "macintosh" 
theme/style (enough examples of kate and kcalc, among others, have been 
posted). It looks like the underlying code hasn't that much evolved since Qt 
4.8.7, so I'm expecting certain issues we identified in KDE4 apps to exist 
under KF5 too. (Indeed, the font issue with the tab selector widget looks very 
familiar.)

- René J.V. Bertin


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> -----------------------------------------------------------
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> -------
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called in the menu methods because only 
> there is it certain that the application actually needs a menubar.
> 
> In line with experience and feedback from the KDE(4)-Mac community I have 
> decided to force the use of native dialogs rather than the ones from the 
> KdePlatformPlugin.
> 
> In addition I set the fallback value for `ShowIconsOnPushButtons` to false in 
> line with platform guidelines, and ensure that the autotests are not built as 
> app bundles.
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt 7c2129c 
>   src/kstyle/CMakeLists.txt bc26667 
>   src/kstyle/kstyle.mm PRE-CREATION 
>   src/platformtheme/CMakeLists.txt 23f590e 
>   src/platformtheme/kdemactheme.h PRE-CREATION 
>   src/platformtheme/kdemactheme.mm PRE-CREATION 
>   src/platformtheme/khintssettingsmac.h PRE-CREATION 
>   src/platformtheme/khintssettingsmac.mm PRE-CREATION 
>   src/platformtheme/main_mac.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126198/diff/
> 
> 
> Testing
> -------
> 
> On Mac OS X with Qt 5.5.1, KF5 frameworks 5.16.0 and QtCurve git/head.
> 
> I have not verified to what extent my use of a private `QGuiApplication` API 
> links builds to a specific Qt version (I consider that nothing shocking and a 
> minor price to pay).
> >>> Do I need to add some glue to the CMake file so that it will warn if the 
> >>> private headerfiles are not available? Apparently no changes were 
> >>> required to find them.
> 
> 
> File Attachments
> ----------------
> 
> purely native OS X theme
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/650d0da7-52b3-40d1-a1f9-cb610494cf77__Screen_Shot_2015-11-30_at_15.42.31.png
> native theme but with `-style kde`
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/72e2a6aa-2a7c-465b-b404-fc1e52b6fc69__Screen_Shot_2015-11-30_at_15.43.02.png
> using the KDEPlatformTheme
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/309e5995-74fa-42fb-a6f3-936cedbf5246__Screen_Shot_2015-11-30_at_15.43.31.png
> on Linux, using a purely "native" theme
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/eaa1d907-bf05-4ca2-821b-83dc062aea04__QtCreatorNativeLNX.png
> KDEPlatformTheme with the "macintosh" native theme selected
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/01/de55a91f-3500-4db8-8a3b-d252fd7ea169__Screen_Shot_2015-12-01_at_13.52.35.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to