Multiplatform frameworks

[René J.V. Bertin]

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 at kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac