wiki:KDEProblems

Problems of KDE software on MacPorts

Why these pages?

When software is ported from one hardware or operating-system environment to another, problems arise that are nobody's fault. The original software writers can try their best to avoid such problems, but they cannot be expected to foresee every issue. These pages are a place where issues of KDE software on MacPorts can be gathered together for easy visibility and people from KDE and MacPorts can co-operate to narrow each issue down to a point where it can be assigned to a specific area on the KDE Bugtracking System or the MacPorts Ticket System for action. Also, co-operation is needed to set up a continuous testing system, in the longer term, to minimize problems in the future.

These pages were initiated by this post on KDE-MAC and a PM discussion regarding Randa Meetings participation of MacPorts developers.

Special maintainer/developer information - which is not covered in the KDE wiki page - could also be gathered here.


Tickets for specific KDE software issues

Information regarding specific tickets has been moved to a dedicated page.

All other tickets of category "kde4" can be listed in one big table. (Be aware that the generation of this table needs a few seconds on MacPorts' trac.)

New version of KDE applications

We're working on keeping the KDE applications distributed via MacPorts in sync with KDE's official release schedule. However, on MacPorts the current version of KDE libraries and applications is usually a little behind, as only one of us (nicos) is maintaining all these ports.

If you want to support us, please find our up-to-date list of problems for some KDE software ports kept in dports/kde/TODO.txt and report any issues found on KDE-MAC or MacPorts-Devel mailing lists or KDE's bug tracker.

Continuous Integration of KDE software

KDE's developers are running a Jenkins-based CI system for the most of the KDE software. This is fully functioning for Linux (and close to that for OSX) as of now. A Windows-CI system is in development at the moment.

There is also a set of code-vetting software called English Breakfast Network (EBN, for short) which supports all developers in writing cleaner code and documentation.

An overview regarding KDE/CI can be found on a dedicated KDE/MacPorts CI page. If you're interested in setting up an alternative CI system, you can check the current status of an OSX/CI system based on MacPorts which doesn't require Jenkins in order to function.

Qt5 and KF5

Qt5 eventually leads to the new KDE Frameworks.

This means that we can soon start adding KF5 frameworks as new ports.

An important issue is that the introduction of KF5 will take a while and thus needs to be made in such a way, that Qt4/KDE4 and Qt5/KF5 frameworks and applications can coexist with one another. The initial qt4-mac and qt5-mac ports couldn't be co-installed, however. This is why René has put a lot of effort into bringing a concurrent variant into qt4-mac and qt5-mac. This was eventually superseded by non-exclusive versions of port:qt4-mac and a new port:qt5 developed independently by their original maintainers, taking the simpler approach of installing all of Qt into dedicated sandboxes and without any of the proposed adaptations for improving the KDE experience (or even making it possible, for KF5, see below). It was thus decided to convert René's port:qt5-mac into a dedicated port:qt5-kde (see #48967), designed to act as a drop-in replacement for port:qt5, much like a more usual port:qt5-devel would act. This is stable and reliable in our (currently only René and Marko) testing, currently pending submission and would benefit a lot from more widespread testing "in the wild".

The KDE4 ports all install and expect their shared resources in "XDG-compliant" directories, mostly under ${prefix}/share, just as they would in their native ecosystem under Linux. This is handled automatically and works because Qt4 doesn't do anything to point running KDE4 applications elsewhere. With KF5, those resources are still installed to similar locations unless the build system is patched extensively, but the information where to find them (in running applications) now comes from a Qt5 class (QStandardPaths). On Mac, this class is hardwired to provide Mac-like paths like /Library/Application Support. In itself this is not an issue, but it's not the way things are installed in MacPorts, and it would also mean that other XDG-compliant applications not based on Qt5 will not know about services provided by KF5 applications - this includes DBus. We have thus chosen the approach of patching QStandardPaths in port:qt5-kde. More details are given in the qt5-kde ticket on trac, but suffice it to say that this patch has been done properly; whether or not QStandardPaths actually returns different (XDG-compliant) paths depends on a token used while building a dependent port. By default the change is dormant, and native, Mac-like paths are used. KF5 ports can in principle be built with the mostly stock port:qt5, but this is unsupported and even untested (and many things will not work properly because of the reasons outline above).

The KDE developers consider KF5 a successor to and replacement of KDE4, so KF5 applications are not designed to co-exist with their KDE4 predecessors in the same prefix. Given the complications of introducing KF5 ports into MacPorts we do support concurrent installation wherever possible, but this requires changes to the KDE4 installation layout which haven't yet been committed, and also some adaptations in individual ports. A few KDE4 ports must be installed with the +kf5compat variant, while most KF5 ports have a +kde4compat variant which makes co-installation possible.

So, if you're enthusiastic about Qt5 and/or KF5 on MacPorts, please support us!

If you want to get your hands dirty and help as a beta-tester, there are 2 github repositories you can install and add (in sources.conf) as additional port trees. Regular "snapshots" of the development state are made to Marko's fork (github.com/mkae/macstrop), which mostly contains ports related to KF5 and/or Qt5. Development takes place in René's "macstrop" repository (github.com/RJVB/macstrop) which also contains a number of unrelated ports and is thus less suitable for the "fainter of heart".
Both come with detailed installation instructions.

Current KF5 ports include kf5-kate (KDE's advanced text editor), kf5-kdevelop (a full-fledged IDE), kf5-kile (an integrated TeX/LaTeX environment), kf5-kdenlive (non-linear video editor), kf5-krita (photo editor) and kf5-digikam (photo management application).

Some relevant tickets on trac:

#48967 - submission: port:qt5-kde
#50966 - Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family
#46240 - kde4 1.1 PortGroup file adaptation to qt4-mac +concurrent

Some older tickets:

#46238 - co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent
#46496 - co-installable qt4-mac and qt5-mac step2 : qt5-mac
#46536 - qt5-mac-devel submission: provides Qt 5.4.x
#47047 - qt5-mac-mysql-plugins
#46239 - qca and qca-ossl adaptations to qt4-mac +concurrent

Other stuff:

#46558 - phonon-backend-gstreamer update to 4.8.2 and qt5 support
#46552 - phonon update to 4.8.3, with Qt5 support

This is the starting point for KF5:

#46978 - extra-cmake-modules (being the basis for creating KF5 ports)
#48184 - kf5-attica plus new kf5 port group

A little visual proof of how far we've come:

This shows KDevelop5 and Konsole5 and the application style selection dialog running with Qt 5.7.1 (provided by port:qt5-kde-devel), KF5 Frameworks 5.29.0 and the QtCurve/MacOSX-Graphite theme. The style selection dialog runs in native Cocoa mode, while in this image KDevelop5 and Konsole5 are running using the X11 backend (provided by port:qt5-kde-devel-x11). Using the native application style and Cocoa mode, KDevelop looks like this:
.


Additional information


Other resources

Last modified 3 months ago Last modified on Jan 3, 2017, 6:47:54 PM

Attachments (2)

Download all attachments as: .zip