KDE is All About the Apps; Autumn 2021

[René J.V. Bertin]

On Thursday November 25 2021 20:33:22 Aleix Pol wrote:

>Here's the notes for the KDE macOS chat:
>Adoption of the different apps
>    Our dependency on dbus is hindering our opportunity to bloom
>there. Allowing to build without for apps that want to be on mac (and
>windows and Android) is necessary.

This is not entirely true as long as you're not aiming at distribution via Apple's store (and IMHO there are enough reasons not to do that). Beyond that, why be afraid to install an additional dependency if it's needed?
DBus has had native support for and been a good citizen on both the Mac and MS OS for years now (since the KDE4 days at least). IMHO it isn't any more "foreign" to those platforms than (a lot in) Qt itself is. The session daemon can be started on-demand via launchd. Running the system daemon but probably out of scope for the vast majority of KDE applications.
The only question is how to install it if the goal is to avoid distribution via installers. A dedicated "terraforming" framework could be the answer; most Mac users will have some degree of familiarity with applications that ask permission to (fetch and) install some dependency when they first start up.

There might be native mechanisms that applications could use on Mac (and/or MS Windows) as an alternative to a dependency on DBus. If so, this could be (or have been, already) implemented via an abstraction layer in Qt. I tried to get a discussion about this going on one of the Qt lists years ago, never got anywhere. And maybe that's understandable: why would an abstraction layer emulate the (Qt) DBus API on the client-facing end?

>who cares for KDE on mac?

I do, but a priori only for as long as my current Mac still runs (and not enough to update it so I can use the latest Qt and KDE versions)... O:-)

I'm missing something here, a discussion of the build system. From what I've seen (up to and including 5.60.0), every application that provides an "official" Mac build has its own recipe for creating a proper app bundle which may or may not be based on Kate's recipe. There should be support in the ECM for tailoring the various install locations to streamline the process (and also to take the Mac version of the QSP path into account). That said, it should be possible to override this (i.e. not coupled directly to CMake's APPLE token), for those of us who build KDE applications for installation into a shared parallel prefix (MacPorts, HomeBrew, etc). A few years ago I wrote an initial skeleton implementation of such support and put it in a task on phab, where it must still remain.

R.