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

List:       kde-mac
Subject:    Re: [KDE/Mac] Multiplatform frameworks
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-03-01 9:17:08
Message-ID: 5168961.nZ5utTtmRj () patux
[Download RAW message or body]

On Sunday March 01 2015 17:37:35 Ian Wadham wrote:

Hi Ian

> Let me kick off by saying that I am not necessarily in favour of "doing what
> the Romans do"… ;-) 

Heh,  I got that! :)

> And I do not like directory names with a space in them
> either, but that is just an annoying detail...

I *hope* it's just a detail...

> Modifying Q(Core)Application's constructor might not work in all cases (e.g. QSP)
> because there may be processes that do not use Q(Core)Application, even if they
> use Qt.  I am thinking of klauncher5, etc.  OTOH, you could just do extra patches
> for those processes...

Yeah, I know I wrote Q(Core)Application, and later on I realised I should have \
referred to the QSP ctor. But it seems it doesn't have one, it's just a class with \
static methods, right? Which would still allow us to add an additional argument with \
a configurable default value where required...

I've started to look at how the ApplicationAttributes (AA_*) feature works. That's \
just a static member value of a private QApplication subclass, which is initialised \
outside of a function. That would only work to define a default at Qt's compile time, \
and not at the client compile time like I am after. Still, one might think of a \
solution in which that additional argument to the QSP functions is set to "use \
whatever the AA_QSP_FLAVOUR attribute dictates" in "stock Qt", and can take other \
values to override that attribute. That's similar to the approach Qt follows for \
QAction menuRoles (cf. TextHeuristicsRole).

> Another possibility (an Apple way… ;-) ), is to use Custom Keys in .plist files \
> [2].

Yes, but that too would require reading out the values, and of course there's the \
issue that 1) not all applications have plist files and 2) even those (app bundles) \
that do, most have a standard plist. 

> On a "per app" basis, you can insert values in Info.plist, using an \
> Info.plist.template file in your CMake build (as you well know, René, but I am \
> telling others).

Yes, or you could modify the standard plist template that I'm guessing must exist \
somewhere. Still that's a lot more modification that I'd hope for, even if it has the \
advantage of shifting it from the source code to the build system.

> Some examples;
> /Library/Preferences/org.cups.printers.plist    Host's list of known CUPS printers
> /Library/Preferences/com.apple.TimeMachine.plist    Host's backup preferences
> ~/Library/Preferences/org.cups.PrintingPrefs.plist    My CUPS printing preferences

Those would be the settings of server applications, not of a library your app links \
to...

> A shared .plist could contain whatever you liked (e.g. a prefix and a base for
> alternate standard paths).  It could be read, using Cocoa methods, the first time
> QSP is called.

Without QSP ctor I think it doesn't make too much sense to follow a "first time only" \
approach, and besides most code I've seen that does similar things seems to read the \
dictionary at each invocation. Presumable with the idea that the settings could \
change (which wouldn't make too much sense here).

> could have a file at /Library/Preferences/org.kde.qt_tweaks.plist, but we would
> still need a way to tell Qt libraries to look at it (or not)… :-(

As I already noted above. It sounds nifty, but I fear that in the end it just adds \
complexity by adding a platform-specific alternative to functionality that already \
exists (QSettings). (Who knows, maybe there's even a Qt interface to handling plist \
files, because the C code for reading them gets very elaborate/chatty very quickly.)

R.
_______________________________________________
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]