"non standalone app bundle" builds on Mac

[René J.V. Bertin]

On Monday November 07 2016 18:14:35 Jaroslaw Staniek wrote:

Hi Jarek,

>​Thanks for the interest!
>In addition Kexi-specific things can be discussed at a ​kexi-devel list :)
>There were enthusiastic people interested in contributing Mac builds of
>Kexi but they disappeared so this task is open for maintainer. Bundling or
>discovering server installation(s) (pgsql, mysql), bundling dependencies --
>these are all task for adoption.
>​
>
>In my opinion Kexi fits to a standalone path, just like on Windows, to
>become as native as possible, well, but not more native than that. For

Right, then there was Kexi too :) It that has been split off the rest of Calligra it's likely to be much smaller. It's also much more unique in its approach - if I'd discovered a use for it myself I would have started working on a port a while ago (port in MacPorts speak; ideally that's just a build script, Portfiles, that tells CMake where to install and get dependencies from).

I've never been against making more-or-less standalone app bundles for Mac, though I do feel that for an application family like KDE it would make sense to put as much of the shared resources as possible into something that's installable independently, e.g. a "meta framework" (a bundled collection of libraries, for which Apple used the term before KDE, the confusion is not on me ;)). It'd be an interesting exercise for a more seasoned Mac developer than I am in this aspect, but it ought to be possible to bundle all KF5 frameworks that way into an object that can be installed into /Library/Frameworks. That'd be a perfectly native approach too, with a priori significant maintenance advantages, but out of scope in this conversation.

Either way, I've always felt that making applications really work well on OS X was a higher priority than the kind of ribbon you wrap it up with. If you want to know what's feasible to preserve in a feature set used on a different platform you start by working in conditions that are as close as possible to those on that platform. In this case, installing shared resources into a prefix much like pkgsrc and gentoo prefix do, as well as MacPorts, Fink and HomeBrew on Mac (which some consider "nice for linux refugees" which isn't untrue but completely beside the point).

Anyway, it's an approach I've been following for about a year now, and it's allowed me to contribute back quite a few improvements to KDE. The thing is that even if I were personally motivated to move on to tweaking the build system to make nicely wrapped-up autonomous app bundles where each app ships with yet another copy of all those Qt and KF5 libraries, I'd still have enough hay on my fork maintaining those MacPorts packages. Adding to that collection is a lesser and to me more satisfying investment than changing course.

In short, I'll try to look into Kexi soonish, but I think I shouldn't be be getting involved while it's still undergoing review (remember, hays and forks).

FWIW, as I wrote to Boudewijn, I think it'd make sense to investigate dumping cmake as the build system for "really native Mac" builds. Figure out once how to invoke cmake so that a project is built and installs as much as possible the way it should end up inside an autonomous app bundle (i.e. using Contents/MacOS and Contents/Resources, those are the only imperative folders I know of). Then use the CMake Xcode generator to create an Xcode project. Use the Xcode project from there on for Mac "bundled build"s, and cmake for everything else.

>example KFileWidget being very Plasma-oriented is close to be removed on
>Windows and could be also removed on Mac, in favour of a Url field + [..]
>button (KUrlRequester).

I have mixed feelings towards the KDE file widget. It's not uncommon that applications provide a non-stock file widget (in fact that's almost exactly what Qt's file dialog is) and KDE's has a number of very useful features that are missing in the Mac file dialog (like tree view). Put it into directory-selection mode however and it's really feels out of place (I much prefer the Mac approach here).

>I've also not seen Mac builds of Kexi-derived projects: KDb, KReport,
>KProperty. These are general-purpose frameworks and Kexi dependencies. If
>they are missing for Mac it would be nice to see them available too as

If? Is there reason to suspect that building them on Mac is going to require patching?

>frameworks for general use.

Framework in which sense? :)

R.