> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > > I guess I can simply fork `frameworkintegration`, change the project name > in the toplevel CMake file and strip everything except for the platformtheme. > > How does this work from that point onwards? > > Martin Gräßlin wrote: > > I guess I can simply fork frameworkintegration, change the project name > in the toplevel CMake file and strip everything except for the platformtheme. > > That's kind of how I did it for plasma-integration with git filter-tree. > > > How does this work from that point onwards? > > My suggestion would be to create something like an "OSX integration" > project in the metadata and have then all your repositories grouped there > including the new platform theme. > > René J.V. Bertin wrote: > This is something I'm completely new to; what metadata are we talking > about here? > Also, can anyone with commit access to existing repositories also create > new ones on the server, and in what category would you suggest putting this? > > Boudhayan Gupta wrote: > For now, start with a scratch repo. Sysadmin will take care of the rest > for you. > > René J.V. Bertin wrote: > As I said, creating or proposing a new KDE package/repository is > completely new for me, even that instruction is still ambiguous. I take it > you're not talking about a scratch repo that exists only on one of my disks, > possibly not even on a remote mirror like github, but rather something that > would alert the sysadmins who will then take the appropriate actions? > > I guess I should look through the developer/contributor instructions > again, I most certainly skipped this level of information when I first (and > last...) read that documentation. > > Elvis Angelaccio wrote: > Here you can find the instructions to create a scratch repo: > https://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_scratch_repositories > > René J.V. Bertin wrote: > ah, great, thanks. Looks exactly what I need except that it doesn't > appear to say anything about the metadata Martin mentions. But it's a start :) > > Martin Gräßlin wrote: > The metadata is in kde-build-metadata.git > (https://quickgit.kde.org/?p=kde-build-metadata.git ) > > René J.V. Bertin wrote: > Right, that metadata :) > Seems that will be among the last things to update; I don't see any > project from scratch mentioned in that repo. > > I've begun setting up an OS X Integration project. For some reason my git > install lacks the filter-tree command so I've gone the manual route copying > the frameworkintegration repo with the patch from this RR. I've removed all > files that shouldn't be included, changed names etc (haven't pruned the > dependencies yet), and committed to `scratch/rjvbb/osx-integration`. Very > much a work-in-progress; I'll have to update my own install (and "ports" > tree) to 5.22 before I can check building (though I presume it *should* build > against 5.20.0 if I downgrade the dependency requirement). > > I just realise this gives the repo a commit history that's a *lot* larger > than the current code base. Is there something I should and could do about > that? > > David Faure wrote: > It's `git filter-branch` (not filter-tree). You should use it to avoid > the history of the stuff from other subdirs.
Dang, it looks like it's too late. I've tried `git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r -f src/kstyle src/integrationplugin src/infopage' HEAD` and that appears to rewrite lots of things ... without actually making the output of `git log` any shorter or the size of `.git` any smaller. - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/#review95538 ----------------------------------------------------------- On May 16, 2016, 9:49 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 May 16, 2016, 9:49 p.m.) > > > Review request for KDE Software on Mac OS X, KDE Frameworks, Plasma, 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 > ----- > > CMakeLists.txt 6ea1cba > src/CMakeLists.txt 1c54eb2 > src/platformtheme/CMakeLists.txt PRE-CREATION > src/platformtheme/config-platformtheme.h.cmake PRE-CREATION > src/platformtheme/frameworksintegration-5.16-font.sh PRE-CREATION > src/platformtheme/frameworksintegration-5.16-font.upd PRE-CREATION > src/platformtheme/kdemactheme.h PRE-CREATION > src/platformtheme/kdemactheme.mm PRE-CREATION > src/platformtheme/kdeplatformfiledialogbase.cpp PRE-CREATION > src/platformtheme/kdeplatformfiledialogbase_p.h PRE-CREATION > src/platformtheme/kdeplatformfiledialoghelper.h PRE-CREATION > src/platformtheme/kdeplatformfiledialoghelper.cpp PRE-CREATION > src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION > src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION > src/platformtheme/kdeplatformtheme.h PRE-CREATION > src/platformtheme/kdeplatformtheme.cpp PRE-CREATION > src/platformtheme/kdeplatformtheme.json PRE-CREATION > src/platformtheme/kdirselectdialog.cpp PRE-CREATION > src/platformtheme/kdirselectdialog_p.h PRE-CREATION > src/platformtheme/kfiletreeview.cpp PRE-CREATION > src/platformtheme/kfiletreeview_p.h PRE-CREATION > src/platformtheme/kfontsettingsdata.h PRE-CREATION > src/platformtheme/kfontsettingsdata.cpp PRE-CREATION > src/platformtheme/kfontsettingsdatamac.h PRE-CREATION > src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION > src/platformtheme/khintssettings.h PRE-CREATION > src/platformtheme/khintssettings.cpp 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 > kate built by Christoph Cullman as a completely standalone app bundle > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/12/d5f9a983-a077-4a52-913e-5d980e62daca__kate-Cullmans-appbundle.png > kate/MacPorts in fully native Mac mode (but using XDG-compliant QSPs). > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/12/02dbfc58-445c-48f5-88ad-33b5ab55571a__kate-MP-fullnative.png > kate/MacPorts using the QtCurve style (but the native platform plugin) > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/12/c9d1e28e-6684-4ae3-b05d-1fbc6cde39f4__kate-MP-QtCurveStyle.png > kate/MacPorts using the KdeMacTheme plugin and the macintosh style > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/12/76b1305e-0bf2-4073-a61f-4df59435a198__Kate-MP-plplug-MacStyle.png > kate/MacPorts using the KdeMacTheme plugin and the QtCurve style > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/12/ad54fdf3-a450-4d0b-8a60-8962f537ed6f__kate-MP-plplug-QtCurve.png > > > Thanks, > > René J.V. Bertin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
