[poll] [OS X]: how do you use port:qt4-mac (or port:qt5-mac)

[Jeff Singleton]

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 at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
>