[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths

[Jeremy Whiting]

David,

Those are all good points, I'd forgotten about the aspect of other
applications using frameworks libraries. Your mail made me remember
something that Thiago suggested on irc a couple of weeks ago that may help
also. His idea is using the library/framework's disk location (if that can
be determined at runtime) to get a relative path for other xdg-like
locations. For example if an application that is using sonnet which is in
/opt/local/lib/libKF5SonnetCore.5.dylib is loaded in an application
QStandardPaths could add /opt/local/share to it's GenericDataLocation and
such. As I type this I'm not sure how that would work technically though. I
guess sonnet (and all frameworks that utilize QSP to find their data)
itself would need some code that it called to add such a path to
QStandardPaths somehow right? This solution could be used to get the
"default" path instead of hard coding /opt/local and has the advantage that
it would work when using kdesrc-build which defaults to install into
/usr/local like linux and would also work for any MacPorts install path. It
would also work for any Qt application that uses any frameworks, as long as
the installers for those applications put the frameworks' data files
relative to the frameworks themselves. We could still do the XDG_DATA_DIRS
and XDG_CONFIG_DIRS parsing also for the CI system, but it may not be
needed there either since test applications linking to other libraries
would also get those paths relative to the libraries themselves.

Ok, after a minute of thought it could be implemented like this:
QStandardPaths::addRelativePaths(const QString &path); where path is the
path to a library. Relative paths to this path (converted into absolute
paths) would be added to QStandardPaths values at run time. Then each
framework that uses QSP to find data files could in any constructor do
QStandardPaths::addRelativePaths(mypath); once and be done, right?

More food for thought.

BR,
Jeremy

On Sun, Jan 4, 2015 at 4:04 AM, David Faure <faure at kde.org> wrote:

> On Saturday 03 January 2015 15:12:36 René J.V. Bertin wrote:
> > On Saturday January 03 2015 12:00:50 David Faure wrote:
> > > It's not Qt that puts stuff into ${prefix}/share and ${prefix}/etc/xdg,
> > > it's the apps.
> >
> > Hmm. So even if changing this kind of setting (adding paths to the front
> of
> > a lookup list) in a new bit of code prepended to the standard
> > Q(Core)Application initialisation routine, I'd personally still prefer to
> > activate that selectively. Probably through a compile-time flag, to avoid
> > having to change client code.
>
> A compile-time flag ... for Qt, or for apps?
>
> For Qt would be a very bad idea, unless it's customary to install Qt twice
> on
> the system, once in a proper Mac OSX location and once in a MacPorts
> location?
> If that's not how people do this, and a single Qt is used, then a
> compile-time
> flag for Qt can't work.
>
> For apps ...well, I don't see how that flag would affect the behavior of
> QStandardPaths. Unless you add code to every app that uses a framework, but
> then it's about adding some code in main() (bad idea, not modular!), not a
> compile-time flag (-Dsomething).
>
> > > Well, my initial suggestion was to add support for XDG_* env vars to
> QSP,
> > > we could do that *without* a default value of /opt/local (unlike my
> > > current patch), so that nothing happens unless these vars are set. It
> > > would do exactly that - not affect non-MacPorts apps. This would indeed
> > > be "less intrusive".
> >
> > Only if you can set those variables only for the applications that
> require
> > them!
>
> I have to disagree with that "fear of breaking things by adding search
> paths".
>
> For instance, on my system I have XDG_DATA_DIRS set globally to my own KDE
> install prefix (+ /usr/share of course). And yet I use apps that don't need
> this (firefox, skype, libreoffice, etc.). And what breaks? Nothing. They
> don't
> care for the extra lookup path, since they are looking for their own
> things,
> which are not in there anyway.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150104/e2a1883c/attachment.html>