[KDE/Mac] Multiplatform frameworks
iandw.au at gmail.com
Mon Mar 2 03:05:01 UTC 2015
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 ,  and  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:
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).
Cheers, Ian W.
More information about the kde-mac