<div dir="ltr">René<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 3:09 AM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tuesday January 06 2015 19:05:36 Ian Wadham wrote:<br>
<br>
>> And not just apps coming from the KDE community, but any Qt app that install<br>
>> stuff into /opt/local/share…<br>
><br>
>Yes, indeed.  However, the apps coming from the KDE Community would be<br>
>the vast majority at present.  I think they are also the main users of DBus, FWIW.<br>
<br>
</span>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.<br>
<br>
(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.)<br>
<span class=""><br>
>Not sure what they do.  I don't think they would link to MacPorts' copy<br>
>of Qt.  Not every Mac has MacPorts and FOSS, some have Homebrew<br>
<br>
</span>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 ...<br>
<span class=""><br>
>The XDG_* variables should be supported in our QSP patch, for the benefit<br>
>of KF5's Apple OS X CI, kdesrc-build users on Apple OS X and people like<br>
>me, who, through an accident of fate and horrid, plastic Toshiba hardware,<br>
>find themselves developing KDE Community code on a MacBook… :-)<br>
><br>
>We should probably also support configuring the Macports XDG base,<br>
>for guys like René Bertin and Nicolas Pavillon (the Macports developer),<br>
<br>
</span>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.<br>
<br>
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.<br>
Indeed: I'd make a perfect member of a community like the one that's perpetuating the KDE3 DE (Trinity?) :)<br>
<br>
> > 3. We want (maybe?) our applications to be downloadable dmg files that can<br>
> > simply be copied into /Applications and run.><br>
> Items 1 and 2 agreed.  Item 3 would be amazing.  Longer term, I think we<br>
> would need code in QSP pick up the current MacPorts prefix, rather than<br>
> hard-coding /opt/local/share.  Or even to pick up a Homebrew prefix, etc.<br>
<br>
Dream on ...<br>
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 ...</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
><br>
> > Actually for 3 I have some questions. On OS X do applications typically<br>
> > bundle everything inside their .app or do some install for example a<br>
> > shared copy of Qt or other libraries? I've seen mention of VirtualBox and<br>
> > other applications on the other thread. Do they all put Qt inside their<br>
> > .app folder?<br>
<br>
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.<br>
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??).<br>
*) 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.<br></blockquote><div><br></div><div>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></div><div><br></div><div>BR,</div><div>Jeremy</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
R.<br>
_______________________________________________<br>
<a href="mailto:kde-mac@kde.org">kde-mac@kde.org</a><br>
List Information: <a href="https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac" target="_blank">https://mail.kde.org/mailman/listinfo/kde-mac<br>
KDE/Mac</a> Information: <a href="http://community.kde.org/Mac" target="_blank">http://community.kde.org/Mac</a></div></div></blockquote></div><br></div></div>