[KDE/Mac] Multiplatform frameworks

[Aleix Pol]

On Fri, Feb 27, 2015 at 10:21 AM, René J.V. <rjvbertin at gmail.com> wrote:
> On Thursday February 26 2015 20:03:32 Jeremy Whiting wrote:
>>Yeah, obviously to share with all users installing data files into
>>/Library/Application Support/ is better, I just didn't do that in my test
>>since my user doesn't own that folder and I didn't want to install with
>>sudo for a test.
>
> True, but (something I didn't want to mention straightaway) that too may be problematic with MacPorts. The solution there *might* be to use ${prefix}/Library/ApplicationSPACESupport, but I really don't see the point in going there instead of using more traditional paths.
>
> Then there's the issue that the user may also have non-KDE FreeDesktop applications installed through MacPorts (or Fink or ...), and those would still expect their stuff in the usual places, part of which will be shared with KDE. I don't like the idea to duplicate that stuff.
>
> We could probably work around that by installing the data stuff in the usual places and modding the build system to install links to those places somewhere under /Library/Application Support so that QStandardPaths point to the right places through these links. I think MacPorts does that already with launchd plists that live under ${prefix}/Library/Launch{Agents,Daemons}.
> But I'd still prefer to patch Qt, and will try to come up with a draft implementation of my runtime selection with compile-time default in the coming days.
>
> One more thought: the majority of *users* probably won't care exactly where the shared data stuff is installed. IMHO that means we can be egoists to some point, and chose what's most convenient for us for our daily dev/maintenance habits. For me that's clearly to stick as closely as possible to "linuxy paths", and certainly not to go for a path that has a space in its name... (among the 1st things I do on a virgin OS X account is `ln -s "Application Support" ~/Library/AppSupport` ...)
>
> R.
>
>>
>>On Thu, Feb 26, 2015 at 7:26 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>
>>> On Thu, Feb 26, 2015 at 10:45 AM, René J.V. <rjvbertin at gmail.com> wrote:
>>> > On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote:
>>> >
>>> >>QStandardPaths there that worked pretty well. In discussion with the Qt
>>> >>developers I began to think that we maybe should be installing our data
>>> >>files in the places that QStandardPaths expect to find them, rather than
>>> >>get QStandardPaths to find files in linuxy paths.
>>> >
>>> > Even if that were the easy way out, I don't think it's the proper
>>> solution if not only because OS X and MS Windows are multi-user machines
>>> and are maybe more often used like that than Linux desktop installs.
>>> Installing stuff in $HOME/Library/Application Support is thus not an option
>>> (besides, there's that obnoxious space in the filename that's bound to
>>> cause issues).
>>> >
>>> > If we can't find a best-of-both-worlds solution that we all agree on and
>>> can go into Qt, we'll just have to roll our own (which might be
>>> incorporated after all once it's proved its value ;))
>>> >
>>> > Reminder to self: add my views to wherever we decided to continue the
>>> stalled discussion from gerrit.
>>> >
>>> > R
>>>
>>> IIRC, the solution is using /Library instead, although my OS X
>>> knowledge is rusty.
>>>
>>> Aleix
>>>
>

I think that if we want out applications to play nice on OS X (or any
other OS for that matter), we'll have to make the applications adapt
to how the OS does.

I only see small improvements by making our applications behave on OS
X as if it was on GNU/Linux. I'd say let's understand how the adopted
system works and blend in it as much as possible. We have the tools:
Qt is already doing that (and that's part of the reason for this
thread) and cmake is very adaptable to the platforms. I don't see why
we shouldn't leverage all that.

Aleix