Changes between Version 104 and Version 105 of KDEProblems

Timestamp:

Nov 7, 2016, 6:01:21 PM (8 years ago)

Author:

mkae (Marko Käning)

Comment:

improve formatting

KDEProblems

@@ -44 +44 @@
 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 .
+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.