On Thursday September 24 2015 22:56:37 David Faure wrote:
> [warning: long, and I change my mind mid-way; I left it all so you can follow
> my reasoning]
Seems like a gradual change of mind :)
> If you're really only thinking of apps made by the KDE community, I would be
> surprised to see any one of them not linking to kcoreaddons.
Point is I don't know ... but it will probably be the case. Apps that link with
more than just 1 or an eclectic selection of KF5 frameworks, and that (indeed)
are supposed to interact with each other. That latter is the crucial bit of
course: without interaction (direct IPC or indirectly via shared resources even
if as trivial as icons) there is no real point in imposing specific locations
that all those interacting apps agree upon. We can probably even be more
selective: resources that are not part of some Freedesktop specification but
are by definition/design shared *only* among KF5 applications can probably be
anywhere (under a common root that can be configured, preferably) as long as
it's indeed a shared location. We'll probably be excluding KDE4 applications
here; if I understand correctly they can continue to work as they do currently
on OS X/MacPorts since their's no Plasma desktop to comply with; as long as the
KDE4 libraries and KF5 frameworks and respective other shared stuff don't enter
into conflict.
(FWIW, with GUI applications being built as app bundles anyway, it ought even
be possible to have, say, Kate4 and Kate5 installed in parallel.)
> I want to stay on record saying that this goes against the modularity
> principle
> of KF5 for other applications, of course. If someone wants to only use
> KItemModels,
The modularity principle for *other* applications? Does that mean that there's
official leeway for, erm, non-other applications to require a common subset?
Also, it strikes me as bit of a gamble not to have implemented a framework for
dealing with what one might call Freedesktop or XDG compliance, but to have
left that to QStandardPaths, basically. It must have been clear from the onset
that QSP complies with Freedesktop/XDG conventions only in standard Unix/Linux
Qt builds (OS X being a "deviant" Unix configuration).
I guess that outlines another possible solution: create a framework that can
provide the required glue on platforms where this might be required or desired,
with build switches to control optional behaviour *and* ensure that all
applications still end up using the same conventions.
> So OK, kcoreaddons could switch QSP behavior on Mac, provided that
> it's documented with a huge warning, and that it can be turned off. It breaks
> the principle of least surprise ("ever since my app started using one tiny
> unrelated class out of KF5, my users lost all their previous configuration!").
This shouldn't happen when things are done correctly. The choice what locations
are to be used should be made at a global level and apply for the whole
installed KF5 environment. That's why I went with a link-time switch that gets
set immutably when an application is loaded. It's not intended to provide
things like runtime switchable configuration profiles.
> In addition to that, we should still make sure that KF5 frameworks work with
> the default Apple-conformant QSP (either because they don't link to
> KCoreAddons,
You yourself came up with quite a few good arguments why this would be
undesirable if not impossible, but those may have been made with a coherent set
of "KDE Desktop" applications in mind.
> or because someone turned off the QSP-switching), but I totally understand if
> you want to
> leave that to somebody else (to each man his own battle).
I might actually be tempted to participate, but only after everything works to
satisfaction in my own use case scenario whatever :) I'd probably want to have
an uptodate KDevelop to do that kind of work, for instance, and installed via
MacPorts or Fink ;)
> Now, if a global object in kcoreaddons switches QSP behavior, how can someone
> turn that off?
I'd argue that that shouldn't be possible, that the way the switch is flipped
should be set when applications are linked, in the build system. Or in a shared
header file, that'd be fine too AFAIC. Though in that case there should be a
way to override the header's setting, of course. It should be fine to link an
application with an explicit choice for the QSP behaviour, that seems evident.
> In details, my idea would be:
> KCoreAddons has in a cpp file: Q_CONSTRUCTOR_FUNCTION(func1) where func1
> switches QSP to XDG mode.
> If an app doesn't want that: Q_CONSTRUCTOR_FUNCTION(func2) where func2
> switches QSP path to OSX mode.
> If it's guaranteed that the ctor func in the app runs last we're fine.
> Otherwise we need a tristate logic
> (default, forcedToXDG, forcedToOSX) where kcoreaddons would say "switch to
> xdg unless forced to OSX").
> Any OSX linker experts around? :)
Do you have specific Linux-linker features in mind?
> The advantage of this solution compared to your initial question: no build
> system hackery
> (which would break the principle of least surprise even more, I would say).
What I like about a build system modification (esp. at the level of Qt
component selection) is that it's done in places that aren't likely to evolve
frequently. And where, if they do, people will be careful. My experience with
modifying source code (e.g. to make X11 calls conditional) is that not everyone
is very careful to leave such modifications in place, let alone ensure that an
upstream change doesn't break them. I won't call it lack of respect, but
sometimes it feels like that ;)
And that is when it's clear that the code has been made conditional on the
platforms it's supposed to build on. I fear that the risk for that kind of
thing will be even larger when an "exotic" platform relies on a patching
mechanism to alter parts of the code that are not clearly conditional.
>
> One thing I like about this, as a side effect, is that my unittests which
> need to
> have control over *global* QSP paths (which I do by setting XDG_DATA_DIRS
> but I have to skip such unittests on OSX/Windows) could then be enabled on
> OSX.
You should also be able to do that with a build system modification that leaves
a choice, no?
> .... which means the suggested solution here would break third-party libs
> which
> installed stuff into default QSP paths, and then we toggle the mode to XDG,
> and they
> can't find their stuff anymore...
It'd be the responsibility of packagers to ensure that those 3rd party
libraries are patched too, or built with the same switch setting...
> Maybe this needs to be per-method-call then.... :
> * if libA installs stuff into XDG paths, then it would find it using
> QSP::locate(type, filename, XDG)
> * the alternative would be QSP::locate(type, filename, Native), which would
> be the default.
Funny, that was my first approach to solve the issue, and it was rejected at
the time (though possibly by a Qt dev).
> This seems more correct to me after all, no? Porting the KDE code would be
> just running
> one perl script, don't worry about that part.
This could work though, and to avoid that perl script it could be handled
purely in the QSP headerfile with a default mode option that is defined at
build time; MacPorts or Fink devs could add an appropriate -DQT_USES_XDG_QSP or
equivalent to their build settings, while without that the mode argument would
default to Native.
R.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
