Planning to release a beta version of KDevelop for OS X during 5.1

[René J.V. Bertin]

On Wednesday October 26 2016 19:41:54 Kevin Funk wrote:

> Well, that's similar to the Windows situation then: It works. We're not 
> relying on DBus on Windows at all, which works for us. Regarding paths, etc.: 
> fixable.

Of course, but you end up with applications that are more standalone than they could be if you see what I mean :)

> I'll run into that anyway, as soon as I start packing the .dmg...

Yep. Just please don't start hacking the build system to create app bundles in such a way that it becomes the almost unavoidable default (as the Marble devs are doing). If you're going in that direction please consider using something like

if(APPLE)
    option(APPLE_STANDALONE_BUNDLE "Generate a standalone app bundle when building on Apple's OS X" ON)
    add_feature_info("App Bundle" APPLE_STANDALONE_BUNDLE "Generate a standalone app bundle when building on Apple's OS X.")
endif(APPLE)

(IOW, I don't mind if KF5 apps move to building as standalone app bundles by default, as long as it's done in such a way that the behaviour can be turned off at the flick of a switch.)

> That's what I tried to hint at with my "no full Qt/KF5 SDK" remark: No I don't 
> actually want to include cmake or Git. That's not our job, IMO. This is where 
> OS X package managers (e.g. brew, MacPorts) would help out.

OK. In that case you may want to consider adding a global/cross-session config to set the path to toolchain items not provided by the OS or something of the sort (or defaults for often-used executables like cmake, qmake etc). I'm not sure about HomeBrew, but AFAIK MacPorts does not typically add its paths to the launchctl search path:

%> launchctl getenv PATH
/usr/bin:/bin:/usr/sbin:/sbin

This affects applications launched through the Finder (NSLaunchServices to be more precise).

Last time I checked, KDevelop didn't like it at all not finding cmake.

> That's a good point. Shortcuts under OS X are generally a big problem I think; 
> we need to review the shortcuts in KDevelop and check whether they're 
> accessible/sensible under OS X.

They should all be accessible because Qt pulls a rather dirty trick of swapping the Ctrl and Meta key definitions on OS X. As a result Ctrl-C for Copy becomes Command-C, etc. I think there's only 1 shortcut more or less imposed by the OS: Command-, for the Preferences dialog.

I think I succeeded once to export my shortcut settings to file, if I can reproduce that feat I can send you the result for comparison after cleaning it up a bit.

> That's something where a OS X local could help of course :). I remember you 
> fixing a few issues there already.

Trying to at least, though I'm not sure you're referring to attempts to make them more Mac-like or more Me-like! :)

This reminds me of another thing which I haven't had to deal with myself since I started patching Qt: Qt tries its best to guess which menu action has to become the Preferences menu by looking at the menu item text. With KDevelop 4.7 and unpatched Qt this caused the "Configure Selection" project command to take the Preferences menu item place because it was declared first and this happens on a first-served basis. The best way to avoid it is to ensure that menu items which could cause problems have their menuRole set to UnknownRole instead of the default TextHeuristicRole.

And talking about menus, let me repeat that a QAction or QWidgetAction cannot reliably be used in both the toplevel native menubar and in other menus. That's really a problem because you cannot really predict which actions are going to be affected and how - and Qt has stopped printing errors about it. It makes the whole KActionCollection idea a lot less useful.
I found one workaround that avoids this issue: I added a setting to the QtCurve widget style to force user-defined applications to use a "normal", in-window menubar. That works OK for me, but I do hope that at some point the Qt guys figure out a better solution; after all this issue didn't exist in Qt4 at all.

R.