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
