wiki:KDEProblems

Version 104 (modified by RJVB (René Bertin), 7 years ago) (diff)

--

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 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.

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

Some relevant tickets:

#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 (exemplarily) plus new kf5 port group


Additional information


Other resources

Attachments (2)

Download all attachments as: .zip