[KDE/Mac] Multiplatform frameworks

[Ian Wadham]

Hi René,

On 01/03/2015, at 8:17 PM, René J.V. Bertin wrote:
> On Sunday March 01 2015 17:37:35 Ian Wadham wrote:
>> Let me kick off by saying that I am not necessarily in favour of "doing what
>> the Romans do"… ;-) 
> 
> Heh,  I got that! :)

Yeah, but I am keeping an open mind…

>> 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…

I think I saw a ReviewBoard item where the path had to be encoded, so the space
became %20 (or some such).  Are you expecting anything worse?

>> 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…

Yes, that is some strange puppy: a private constructor, but no implementation and
no instantiation anywhere.  And QSP has no data-state ATM, static or otherwise,
except what is on the stack.

It reminded of a bongle Stefan Majewski came up with a few years ago on libkdegames.
See [1], [2] and [3] for the ReviewBoard entry and the latest code (ported to KF5).

This technique gets you in the door way ahead of the crowd, even ahead of main()… :-)

Oh, and I found out today that some GUI apps (maybe all) may have to reference QSP
ahead of creating a QApplication, otherwise there is a risk of them losing the local data
and config files they used to have in KDE 4, see:
    http://lists.kde.org/?l=kde-games-devel&m=142523428426539&w=2

There are migration methods for copying the files from their KDE 4 locations to their KF5
locations, but they seem not to be working in some situations.  The jury is still out on this.

> 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).
</snip>

Cheers, Ian W.

[1]
https://svn.reviewboard.kde.org/r/6810/
[2] https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/chooserastergraphicssystem.cpp
[3]
https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/diff/CMakeLists.txt?rev=748aa8c8f0e262b1edb7a3166a08528b620bf7bc&rev_to=3c7d109436ab58550a662687c04a42e6e4aec7f0