[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Multiplatform frameworks
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2015-03-03 6:09:21
Message-ID: 5383976A-9319-483F-8871-5CD557597CA2 () gmail ! com
[Download RAW message or body]

Hi René,

On 02/03/2015, at 7:58 PM, René J.V. Bertin wrote:
> Anyway, it wasn't very hard to implement a 1st draft of my ideas; see \
> https://bugreports.qt.io/secure/attachment/46944/QSP-patch-20150301.diff . There's \
> no ctor, but there is only 1 function that needs to decide according to what \
> guidelines to construct its return value, at least for now. 
> This is currently in testing on the pixilla VM, including the question "what \
> happens when you call the function with the new argument from code that wasn't \
> recompiled with the new header declaring the variable and its default value" :))

That looks as though it would work fine, but I still do not like that the choice of
policy for standard paths is part of building Qt 5.  I would like to be working
towards having one and only one one copy of Qt 5 in one Apple OS X system.

Stefan's trick would allow you to choose your policy from outside Qt 5, using
a QSP function such as proposed by Oswald Buddenhagen.  Or you could use
a setenv in the "Stefanic" anonymous namespace and a getenv in QSP… ;-)

> BTW, we'd need to discuss whether ${prefix}/config is a good choice for the CONFIG \
> locations; Linux uses /etc/xdg for that and we do have ${prefix}/etc/xdg …

Yes, config paths have to be nailed down too.  I have no strong feelings
about /etc/xdg or ${prefix}/etc/xdg, except that we might as well keep things
in the MacPorts family for now… :-)

I notice that QSP has NO read-only GenericConfigLocation for Apple OS X,
whereas it does for Linux --- a sizeable omission.  I have a feeling KF5
needs such a location.

Re this whole debate about standard paths…

I am beginning to think that trying to fit KDE's extensive sharing of files
between applications, libraries and utilities into standard Apple directories
is VERY foreign to Apple's design philosophy, where apps are expected to
be self-contained (and are completely sandboxed on iOS).

We already have the situation in KDE 4 on Apple OS X where operations
involving plugins, KParts, mime types, KIO and our old friends kdeinit4, etc.
tend to have problems.  Many things are still broken in KDE 4 on OS X.  Trying
to get all that complexity working in KF5, using only Apple paths, is liable to
cause us extra difficulty… :-(

And if anything goes wrong, "do as the Romans do" applied to Ancient Rome,
the Romans being the dominant power.  Apple could get very annoyed if we
cause them any trouble.

Cheers, Ian W.


_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]