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

Tue Jan 6 12:49:51 UTC 2015

René

On Tue, Jan 6, 2015 at 3:09 AM, René J.V. <rjvbertin at gmail.com> wrote:

> On Tuesday January 06 2015 19:05:36 Ian Wadham wrote:
>
> >> And not just apps coming from the KDE community, but any Qt app that
> install
> >> stuff into /opt/local/share…
> >
> >Yes, indeed.  However, the apps coming from the KDE Community would be
> >the vast majority at present.  I think they are also the main users of
> DBus, FWIW.
>
> Don't forget that a (good?) part of what constitutes (or "typically comes
> with") the Gnome desktop is also in MacPorts. In fact, since those use X11,
> it is probably not impossible to run a full blown Gnome DE in a
> (fullscreen/rootless) X11 "session", alongside native apps.
>
> (Comparable to what I did for years, have X11 "on the other side of the
> screen", a bit like on its own Space/virtual desktop.)
>
> >Not sure what they do.  I don't think they would link to MacPorts' copy
> >of Qt.  Not every Mac has MacPorts and FOSS, some have Homebrew
>
> That will depend on how people install them, and I'm of course speaking
> for installing from source. Given that Qt4 isn't going to evolve anymore
> (maybe 4.8.7  later this year), it would make sense to install it through
> MacPorts (or HomeBrew, or Fink) only, if you already use one of those. And
> that's not unlikely IMHO, for "developers". Beats having to build all those
> tools and library dependencies from scratch ...
>
> >The XDG_* variables should be supported in our QSP patch, for the benefit
> >of KF5's Apple OS X CI, kdesrc-build users on Apple OS X and people like
> >me, who, through an accident of fate and horrid, plastic Toshiba hardware,
> >find themselves developing KDE Community code on a MacBook… :-)
> >
> >We should probably also support configuring the Macports XDG base,
> >for guys like René Bertin and Nicolas Pavillon (the Macports developer),
>
> Actually, I find myself using a Mac laptop because back in 2004 I
> discovered that OS X was what "Linux for the Desktop" wasn't yet at the
> time (and clearly wasn't going to be for a good while longer). Ten years
> later, I find myself less and less happy with certain changes to OS X, and
> also discovered that KDE had come of age to a point where things like KMail
> and KDevelop are ready (or almost) to replace Apple's Mail.app and Xcode
> that no longer suit my needs.
>
> Off topic here, but that also explains why I'm not very hot about KF5.
> I've learned to fear updates for the sake of "using the latest and
> greatest", and the little I've seen of KF5 under Linux doesn't ease those
> misgivings, at least not where pure looks are concerned.
> Indeed: I'd make a perfect member of a community like the one that's
> perpetuating the KDE3 DE (Trinity?) :)
>
> > > 3. We want (maybe?) our applications to be downloadable dmg files that
> can
> > > simply be copied into /Applications and run.>
> > Items 1 and 2 agreed.  Item 3 would be amazing.  Longer term, I think we
> > would need code in QSP pick up the current MacPorts prefix, rather than
> > hard-coding /opt/local/share.  Or even to pick up a Homebrew prefix, etc.
>
> Dream on ...
> You'd either need an installer that changes the built-in paths to
> libraries, or you'd need to make framework builds of all dependencies and
> put those in a standard location like /Library/Frameworks . And that's
> certainly not an exhaustive assessment of the situation ...

> >
> > > Actually for 3 I have some questions. On OS X do applications typically
> > > bundle everything inside their .app or do some install for example a
> > > shared copy of Qt or other libraries? I've seen mention of VirtualBox
> and
> > > other applications on the other thread. Do they all put Qt inside their
> > > .app folder?
>
> Talking only about Qt apps, yes, the standard approach *) is to bundle all
> Qt (and other non-system) dependencies inside the app bundle. That's one of
> the reasons why Apple chose that format in the 1st place, so that you can
> just drag an icon to any place you want to install an application.
> VirtualBox and Parallels Desktop both extend that to their helper
> applications that require GUI functionality, and presumably those share the
> same Qt frameworks. I don't know any Qt-based examples, but it is not
> unheard of for application suites to install shared/common stuff in
> /Library/Frameworks, /Library/Application Support, etc. But those will
> rarely if ever be available through the Mac Store (does Xcode still install
> things in /Library/Application Support??).
> *) that'd be for people who provide prebuilt applications, whether they're
> commercial or not. Home developers may have any number of Qt applications
> that are built against libraries installed in any number of locations, of
> course, including Qt installed through the "official" installers.
>

Well it seems other Qt based applications do this. I've got an installation
of VirtualBox here on my mac and it didn't put anything into
/Library/Application Support but does have
Contents/Frameworks/QtCoreVBox.framework QtGuiVBox.framework,
QtNetworkVBox.framework and QtOpenGLVBox.framework within it. At my last
job (STI years ago) we originally statically linked to Qt but after a while
we opted to dynamically link to it, ship our slightly patched copy of Qt
next to our application, changed our binaries to .bin files (same thing,
just renamed) and made the executable a script that set LD_LIBRARY_PATH to
where we shipped our Qt and execute the .bin. I wonder if VirtualBox is
doing something similar. Though looking inside these .framework files
there's no .dylib, just resources, so maybe they are only shipping these to
hold the resources and are statically linking with Qt?

BR,
Jeremy

>
> R.
> _______________________________________________
> 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/20150106/4f05329d/attachment.html>