On Tuesday September 29 2015 09:45:02 David Faure wrote:

Hi,

I appreciate your continued interest (and not having to send a 'bump' message 
:))

>You don't *really* need XDG on OSX. You need files to be found, it's just 
>easier to do that by coying what we do on Linux/BSD ;)

Sure. But if it wasn't clear: for use in frameworks (sic..) like those provided 
by MacPorts those files have to be found in locations where non-Qt code will 
also find them. Which probably leaves little choice ...
BTW, was that an intentional slip-up, coy instead of copy? ;) Question is, what 
would be the real MacCoy? :)

>That is KStandardDirs, and I certainly do NOT want to bring that back. It 
>would go exactly against "all apps use the same conventions"

I would say that it helps impose that "all apps use the same conventions", at 
least that's how I'd implement it.
>because apps using QSP and apps using KStandardDirs would do things 
>differently.

I'm not suggesting to bring back KSD, much as having a patchable proxy class 
would make things easy as they were with KDE4. I'm really only thinking of 
something that provides a hook to modify QSP behaviour in a controlled fashion 
for *all* applications that belong to the class where the native QSP behaviour 
is not appropriate.

>And because it assumed XDG layout everywhere,
>which looks strange on OSX, looks a lot stranger on Windows, and is just not 
>allowed on Android or iOS.

FWIW, I don't see why KSD could not have been rewritten to behave more 
appropriately?

>I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from 
>KF5, say KTextEdit, and my users lost
>all of their previous configuration because this brought in kcoreaddons, which 
>toggled a global switch in QSP!!! You guys suck!!!" :-)

To which you could reply "but you asked for it by configuring your KF5 build to 
modify Qt's behaviour". Not changing stock behaviour by default has clearly 
always been a requirement for me.

>Hidden magic is good because it's hidden so people won't break it? I can't 
>agree to this line of argumentation.

Didn't say it's good, and also didn't intend to hide through obfuscation. 
Rather, hide in plain sight, with a good ample description that would be a bit 
cumbersome in "user source code".
But,
>Anyway, meta discussions won't help, let's dive into specifics again ;)

>Hmm. You envision a world where a single packaging system controls all the Qt 
>based libs.

Indeed, but I don't envision that as the only or even the centre of the 
universe. It just happens to be the world I live on ;)

>I suppose this is the case for Macports (and its alternatives like Fink, 
>assuming people can't
>mix-n-match between the two)? Or can an app in Macports link to a lib from the 
>"real" OSX
>(I guess I mean for instance /Library)?

MacPorts, HomeBrew and (AFAIK) Fink are comparable to things like Gentoo Prefix 
in that they attempt to be as self-contained as possible. It's not even their 
goal to provide libraries and middleware for use in whatever personal or 
professional projects users might have. They exist with the goal to make it 
easy to install (free) software, and strive for reproducible builds (which 
explains the goal of being self-contained). The only outside/system libraries 
that apps in MacPorts are supposed to link to are the system SDKs and a select 
few other libraries which would otherwise lead to circular dependencies. You 
can have MacPorts and Fink installed alongside each other (for users who know 
what they're doing); HomeBrew installs stuff into /usr/local and is thus more 
or less incompatible with anything else.
MacPorts also has the guideline to force applications and libraries to build 
against MacPorts dependencies instead of against any "embedded" copies of those 
libraries that might be shipped with the code. I'm even tempted to say that Qt 
is provided only so that Qt applications can all be built against the same, 
controlled version. Or at least that that argument is at least as important as 
the reduction of the disk footprint.
And yes, MacPorts uses a build and packaging system written in Tcl (running in 
a special tclsh); Fink uses Debian's packaging system and HomeBrew uses 
"recipes" written in Ruby . So all have ways to distribute specific patches 
(like my QSP patch, currently) and perform all kinds of magic .

Which also means that it's perfectly possible to implement some or all of the 
changes we're discussing here in the appropriate MacPorts ports.
That doesn't take away the fact that I need some guidance on how best to 
implement those changes ... and there is a MacPorts guideline that they 
shouldn't be the repository for upstream patches.

>If indeed this is about a self-contained world where all libs and apps should 
>use the same paths,
>then we're back to the easiest solution: a Qt patch for Macports.
>Or the equivalent, an upstream Qt change which is enabled when configuring Qt 
>for Macports.

Yes and no.
Yes, the required patch to QSP can be among the other patches MacPorts applies 
to Qt (there's a whole list, not all of them fixes to known generic issues).
And No, there still is the fact that pure Qt applications should be able to use 
native-style QSP locations. I'd have to discuss whether those locations should 
be really "stock" or whether at least some should point to things like 
/opt/local/Library, but that's an independent question.
The need for a QSP switch comes from this requirement that pure Qt applications 
distributed through MacPorts should behave as much as possible as those built 
against an "official" Qt install.

>If however this is about a mix-and-match world where some libs install files 
>into XDG-like paths
>and some other libs install files into OSX-like paths, and some apps link to 
>both of these libs,
>then neither a compile-time Qt patch nor your idea of a per-app behavior 
>switch would work.

That's evident, but fortunately that is not the case. Libraries that are not 
part of Qt nor of KF5 and that use QSP will themselves be distributed through 
MacPorts (or Fink or ...) too, and can thus be subject to the appropriate 
patches. Which should be largely automatic because in my dream implementation 
it is the application (the end-point) that pulls in the module that will toggle 
QSP behaviour, and this will be effective for all libraries that link to the Qt 
install providing QSP. I won't even evoke the (im)possibility of mixing and 
matching different Qt installs ;) and thank goodness that QSP was not 
implemented using just a set of header files.

>I see in your followup that you want to be able to link to Qt from OSX (when I 
>say that, I mean outside
>Macports), so it's not a fully self-contained world. But why do you want to be 
>able to link with Qt from
>OSX but not with Qt-based libs from OSX? (I'm saying you're excluding that 
>case because of your
>line above, "the packagers must ensure all libs are patched too"). That only 
>works if all libs are
>from Macports, surely.

That's what I referred to above; I don't think MacPorts is really intended for 
this, and I doubt that a lot of support will be given for someone who runs into 
issues doing this (the question of support with free software is always a bit 
... funny, or at least the line "we don't support this" is :)).
Of course, someone using MacPorts to install libraries and other stuff to build 
non-MacPorts applications must make sure that all components agree on all 
conventions, or face the consequences.
So yes, I've been known to use MacPorts this way. Nowadays, I find myself 
simply writing a "personal port" for such applications. Makes updating so much 
easier (including checking for the existence of newer versions), ditto for 
uninstalling, and one very quickly comes to appreciate MacPorts' 
activate/deactivate feature (with its support to keep multiple versions and 
variants "on standby"). That's so appreciable that I've even begun adapting my 
own ports for use on Linux :)

>A little bit too much magic for me, and I suspect for Qt devs as well.
>I could even imagine a case where an app would want per-call choice: if you 
>want to
>use shared-mime-info from /usr/share/mime but still to save configuration into 
>~/Library/Preferences?
>Don't know if that makes sense.

It might; I'm much less convinced that it'd make sense to allow applications to 
differ in this.

>> There's a problem with that approach, though: Qt itself uses QSP
>
>Yes but that is a feature, not a bug :)
>Here's what I mean, in more details.
>
>There are two use cases for QStandardPaths (Config and Data locations, the 
>rest is trivial).
>Case 1: a library installs a file in e.g. 
>share/kxmlgui5/katepart/katepart5ui.rc and wants to be
...
>Case 2: writing and reading user-specific files, into writableLocation(). This 
>matters a lot less IMHO.
>Whether you save stuff into ~/.config or ~/Library/Preferences, you can find 
>it again later as long
>as nobody changes QSP behavior on you.

Yes, user-preferences and anything that's really specific either to Qt or to 
KF5 can go anywhere as long as everyone agrees on how to obtain that location.

>The qlogging.ini file that Qt is looking up falls into this category, it's a 
>user file, not a file installed by Qt.
>However it could be considered confusing if you install *one* Qt on OSX, set 
>up a qlogging.ini file for it
>(in ~/Library/Preferences), and it works for your OSX apps, but not for your 
>Macports apps because
>they toggle QSP behavior *globally* so these apps are looking for this file in 
>~/.config.
>This is an argument in favour of a per-call switch! Qt using Native would keep 
>it looking into the same
>location, no matter where apps want to save config files.

Heh, I have a feeling we're agreeing (without really realising it) and also 
both making things more complicated than necessary (but in different ways).

Your case 1 should be moot as long as everyone involved in that scenario uses 
the same QSP convention, libraries/frameworks and applications alike.
That's probably an argument in favour of implementing at least part of the 
modification in the build system, supposing that some of those files installed 
by libraries are installed (or have templates created) when the library is 
installed. If that's not feasible the idea of using a switch that gets toggled 
during the runtime initialisation becomes a lot less appealing.

As to your case 2: I don't really see any issues. It might be confusing if 2 
different Qt installs behave differently say re: logging, but it might just as 
well be desirable. And however you turn it, there will always be differences 
between different Qt installs on the same host; they won't share plugins 
either. Which could in fact be an argument in favour of separating them as much 
as possible, also at the level of their configuration files (shared and 
per-user).

>I would just like to take one step back and make sure this is going into a 
>direction that makes sense.
>Let's assume you can toggle QSP behavior to XDG somehow (per call or globally 
>or whatever).
>What then? Macports users will have to set XDG_* env vars for the apps to 
>work? I thought
>setting env vars wasn't an option?

No, the part of the patch that takes care of this is largely unmodified from 
what was presented on gerrit a while back. So there are hardcoded locations 
that point in the right direction and that can be overridden with XDG_* env. 
vars (e.g. in scripts and from the command line).

R
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to