[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: [KDE/Mac] Multiplatform frameworks
From: Ian Wadham <iandw.au () gmail ! com>
Date: 2015-03-02 3:05:01
Message-ID: 74305900-C665-42EA-BA9B-EEF1DA04206C () gmail ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic