I use QT4 on OS X for:
KDEnlive (Video Editing)
KeepassX v2 (alpha)
On 2/2/15 4:59 AM, René J.V. Bertin wrote:
Hello,
The central question first: I'd be interested to know how many members of these lists use
Qt installed through MacPorts to build OS X style standalone app bundles (i.e. with Qt
bundled "inside" the application), or app bundles that at least expect to find
their settings and additional data in the usual OS X locations like ~/Library/Preferences
and ~/Library/Application Support (or the global equivalent /Library/Application Support)?
Regular Qt users may be aware that there has been a transfer of functionality
from what used to be a separate framework built atop Qt4 (KDE4) to Qt5. One
example is the KStandardPaths class that has become QStandardPaths, a class
that attempts to give a standard API to obtain the paths where different kinds
of data are stored, distinguishing between system and installation defaults and
user settings, readable and writable locations, etc.
The QStandardPaths on OS X implementation has opted for a very OS X way of doing things,
pointing to locations like "Library/Application Support", /System/Library/Fonts
etc, while the older KStandardPaths returned the kind of paths you'd also get on other
Unix-like OSes, like /opt/local/share .
Below, I'll be using KF5 applications as an example of a potentially much
larger class of applications coming from the Linux/Freedesktop world. Partly
because they are undoubtedly the largest group of such applications, but also a
prime example exactly because QStandardPaths comes from the same heritage, KDE4.
We thus have a kind of dilemma:
1) we cater to applications that are conceived around the Unix
(Freedesktop/XDG) way of doing things where you have central repositories like
/opt/local/share/themes, /opt/local/share/icons etc. This is what KF5 (KDE5)
applications will require, without significant rewriting.
2) we don't touch QStandardPaths and thus have application-centric locations which make
the use of central repositories hard. That will require significant rewriting of KF5
applications, one at a time because KF5 itself no longer provides an intermediate layer
in which we can "hide" our modifications.
3) we find some sort of compromise, which would probably (ideally?) take a form
where a Qt application can indicate which of the 2 options it would like to
subscribe to when it's being built.
When opting for 1) (the easy solution), we can build and install those
applications, and they will work as long as they don't do anything
platform-specific. Most notably, they'll find everything they expect in the
same kind of locations where it would be on Linux. However, this will make it
hard(er) to build completely standalone OS X style app bundles. That won't be
an issue for local use: the Qt build and installation systems will use the same
paths as those used by the applications themselves, so settings and data will
still be found. Just not in the same place.
When opting for 2), Qt applications will build "out of the box" like OS X style
applications, standalone or not, and expecting to find settings and additional data in
the standard OS X locations. This will (and does, in our experience) break most KF5 and
similar applications, and will require a lot of changes to each and every application to
get it to work again. That in itself goes against the principle(s) behind MacPorts, I
think, but it would also impose rethinking of things like how Freedesktop icon themes are
distributed.
Looking forward to (constructive ;)) feedback!
Thanks,
René
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
