[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
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


_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]