[OS X] make kde-workspace build
Review Request #120287 - Created Sept. 19, 2014 and updated
|René J.V. Bertin|
A few rather straightforward patches to make the relevant bits of KDE4's kde-workspace build and function on OS X.
The main interest is having the systemsettings control panel to control the various relevant KDE settings among which desktop search, fonts, colours and even style.
The oxygen style builds and looks good but shows some updating glitches due to compositing.
I'm submitting this patch partly in hope it may be useful in bringing kf5-workspace to OS X, one day.
On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs git/master, 4.14.1).
overall I rather tend to -1 for these changes. I consider changing the build system in a long term release as way too risky considering that the core development doesn't use this iteration any more. Any unintended breakage (e.g. a component also not being built on X11) would probably not be spotted and that's something we certainly don't want to do in a minor version.
Given that we are already in a late state of the bug fix only development it should not be difficult to keep the patch downstream as a distro-specific patch.
While we're discussing krdb's function on non-X11 systems:
I seem to recall that the colour theme selector kcm had an effect like it has under X11: applying the new theme to running applications instantly. I can no longer reproduce this. My work on getting this package to OS X has been a very informal approach. It's only been the other day that I realised it could have some value for the transition to KF5, and rounded up everything, tested with the latest kde-workspace version and then made this RR.
So my recollection can be wrong, and it could even be that it's expectable that KDE/Mac doesn't even respect all colour choices for all GUI elements.
For instance, I'm now seeing that simple applications like systemsettings or kwalletmanager ignore (almost) all colour choices, kate and kdevelop use them for the edit views but not lists/frames and digikam uses almost all selected colours (but that app has a builtin theme selector).
I've reverted to kde-workspace 4.11.9 (the one from KDE 4.12.5; MacPorts keeps snapshots one can switch back and forth between) and as far as I can tell those observations are not the result of my changes to krdb.cpp .
Thomas seemed knowledgable about how Qt4 works on OS X; to what extent is this to be expected, and to what extent might we be able to improve this? (If improvement it is on a platform that basically allows only the text selection highlight colour to be customised...)
What (missing) things might I look for aside updates to kdeglobal.rc (which I realise I haven't even done yet)?
in reaction to the tab character mystery: proof they are not on my end. Just to be sure, the SHA256 checksum is 3989cdd46af3c891e570974d66c330403dcd41c4ee5e17a372fa385080cbabd1 .
patchreview-20140920.patch: - copy of the diff file saved locally, which had no tabs when I uploaded it + copy of the diff file saved locally, which had no tabs when I uploaded it. Checksum: 3989cdd46af3c891e570974d66c330403dcd41c4ee5e17a372fa385080cbabd1
out of interest: this is now a huge NOT WIN32 block with two NOT APPLE blocks. If I see correctly, what remains being built on Apple is:
Somehow I doubt kcheckpass will work on MacOS (it uses PAM) or is of any need (only used by kscreenlocker_greet in ksmserver which is not built). And qguiplatformplugin_kde should not be of any use on MacOS either because it's the Qt plugin for a Plasma session and shouldn't (TM) be used on other platforms.
So if I see correctly you could just merge the whole thing into a
if(NOT WIN32 AND NOT APPLE)
Dropped kcheckpass (could be made to work but seems to be of little use) and qguiplatformplugin_kde, as suggested.
Note that someone looking for a nice programming exercise could port
ksysguardto OS X! Is that component used for anything that could be of actual use on OS X?
Revision 6 (+53 -31)
A new revision of the patchset.
This revision includes the plasma subdirectory in the build, in order to provide the possibility to run plasmoids via plasma-windowed.
In an initial step, te CMake files under /plasma have been changed to exclude the same components on OS X as on MS Windows, i.e. checks are now for
NOT WIN32 AND NOT APPLEinstead of for
NOT WIN32only. Further exclusions were then made for the components that gave build errors due to X11 dependencies.
Plasma-windowed's build process was modified to add an Info.plist that makes the application an agent, i.e. a GUI application without menubar or presence in the Dock or AppSwitcher.
Changes had to be made to the plasma-windowed code to prevent crashing when exiting from a successfully loaded plasmoid through the standard Command-Q quit instead of by closing the window. Replacing all
deleteoperations of QObject-derived class instances with
->deleteLater()was enough to prevent crashing (suggesting that a nested eventloop was the culprit, or at the least an immediate delete rather than a deferred delete compatible with Objective-C's
release(which takes effect when exitting the event-loop in which the release was done)).
I tried making PlasmaApp inherit KApplication instead of KUniqueApplication so that multiple instances can be run concurrently. This has the effect that plasmoids that usually work are no longer rendered.
I'd appreciate pointers on how to circumvent this.
Revision 7 (+126 -40)
I'm not understanding the changes in Plasma Netbook. Why do you want the Netbook shell on OSX while on the other side you disabled the desktop shell? AFAIK you cannot replace the shell of OSX, so having Netbook sounds pretty useless to me.