> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote: > > src/platformtheme/CMakeLists.txt, lines 67-69 > > <https://git.reviewboard.kde.org/r/126198/diff/6/?file=420926#file420926line67> > > > > don't make thie an elsif, just an if. It's not an elseif condition > > René J.V. Bertin wrote: > In practice it is, I think it has more or less been decided to assume > `APPLE` means "no X11". Qt's XCB QPA can currently still be built on OS X > (and is almost completely functional) but there's no guarantee how long that > will still be possible. > > Which should suit some of you, as full-blown X11 support would definitely > give sense to supporting full-blown Plasma sessions (in so-called rooted mode > of the XQuartz server). :P
that's not the point I wanted to make. The changes are independent. We search for X11 independent of whether it's apple, so also on linking it should not be an if/else, but two if. Each of the features (X11 support, Apple support) should get it's own block. It makes things much easier for if it needs to get extended in future. E.g. you could build on Linux without X11 support, then it should not go into any else branch which doesn't matter. Easier to read code and easier to maintain code was the idea I had in mind. > On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote: > > src/platformtheme/kdeplatformtheme.h, lines 41-54 > > <https://git.reviewboard.kde.org/r/126198/diff/6/?file=420929#file420929line41> > > > > why did you add the virtual? The methods are marked as Q_DECL_OVERRIDE > > which implies they are virtual > > René J.V. Bertin wrote: > Q_DECL_OVERRIDE indeed appears to resolve to `override` even with clang; > what about when it doesn't? Not supposed to happen and thus not to worry > about any issues that might cause? > > For now I've left the virtual keywords on definitions that lack > Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead? > what about when it doesn't? It doesn't matter. override triggers a compile error if the base method is not defined as virtual. By reimplementing in a subclass without virtual you're not going to turn it non-virtual. We only used to add virtual in derived classed to increase readability, to indicate that it overrides a base method. Now we have language support for that. > For now I've left the virtual keywords on definitions that lack > Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead? Don't change if it's not needed. If the method is virtual in the base class then don't add virtual. > On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote: > > src/platformtheme/kdeplatformtheme.h, lines 56-61 > > <https://git.reviewboard.kde.org/r/126198/diff/6/?file=420929#file420929line56> > > > > there is no such thing as a protected variable (see e.g. > > https://programmers.stackexchange.com/questions/162643/why-is-clean-code-suggesting-avoiding-protected-variables > > ). If you need to access the variables, please add protected accessor and > > setter methods > > René J.V. Bertin wrote: > That article suggests protected member variables do exist but should be > avoided. Is that what you meant? > > The only one I actually used was mKdeGlobals from the fontsettings class yes they should be avoided up to the degree that one should consider that this is a feature the language doesn't expose. That's what I meant with how I formulated it. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/#review89105 ----------------------------------------------------------- On Dec. 4, 2015, 2:05 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. 4, 2015, 2:05 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 > ----- > > src/platformtheme/CMakeLists.txt 23f590e > src/platformtheme/kdemactheme.h PRE-CREATION > src/platformtheme/kdemactheme.mm PRE-CREATION > src/platformtheme/kdeplatformtheme.h 97d09df > src/platformtheme/kdeplatformtheme.cpp 80dbcb7 > src/platformtheme/kfontsettingsdata.h 4b92c7d > src/platformtheme/kfontsettingsdata.cpp b0a4bbf > src/platformtheme/kfontsettingsdatamac.h PRE-CREATION > src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION > src/platformtheme/khintssettings.h ec064d3 > 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
