[Kexi-devel] RFC: plan for starting the Qt5/KF5 port

[Boudewijn Rempt]

On Wed, 25 Feb 2015, Jaroslaw Staniek wrote:

> On 25 February 2015 at 01:01, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
>> Am Dienstag, 24. Februar 2015, 09:47:41 schrieb Boudewijn Rempt:
>>> As a sidenote, I also want to take the opportunity to do a clean-up step,
>>> but I'm not sure what the right moment or place is. It might even
>>> something to do in the 2.9 branch after tagging...
>>>
>>> * replace all header guards with '#pragma once' -- because errors with
>>> header guards are actually quite frequent, and all compilers support this
>>> pragma now.
>
> Let's either fix the guards or Qt Creator [

The problem with fixing the guards is that it's an ongoing maintenance 
burden. Just like anything else that needs manual attention. It's not a 
big issue for inactive parts of calligra, but lose days a year over it!

But yeah, if Qt Creator is broken, we're stuck.

> https://bugreports.qt.io/browse/QTCREATORBUG-7317 ]...
>
> Other KDE projects would have the same issue, it's apparently not very
> bit if only 263 files use it:
> http://lxr.kde.org/search?_filestring=&_string=%22pragma+once%22
>
> I would delay this change until the tool support it, and especially
> for frameworks I would not use it.

I am not interested in frameworks. If something disappears out of calligra 
into

> So ending up with some files using it and some not does not look clean
> for me, it's a distraction (also in git history).

We're going to touch so many lines of code anyway that this is the moment 
to not care about that, in my opinion.

>
>> Hm, I have not seen this done elsewhere yet, can we be sure that all compilers
>> we are targetting (which I assume would be defined what Qt5/KF5 targets for
>> now) support this? And given you also target the 2.9 branch, which might mean
>> another set of compilers again. CentOS4(?)'s compiler supports it?
>> (Pardon, just stresstesting things I note down)
>>
>>> * rename all krita files to the calligra standard. (cc -> cpp, underscore
>>> -> CamelCaps)
>>>
>>> * from kde-dev-scripts, run:
>>> ** astyle-kdelibs (prevents the astyle problems with foreach and so on)
>>> ** clean-forward-declaration.sh (remove unused forward declarations)
>>>
>>> * from plasma-framework, run:
>>> ** port-qslots.sh (to port to Q_SLOTS and Q_SIGNALS)
>>> ** port-includes.sh (to get rid of the module prefixes in includes)
>>> ** port-cmake-style.sh (to get a bit more consistency)
>>
>> I am not sure everyone of the maintainers is yet convinced that this is okay
>> WRT git blame. Has consensus been reached there meanwhile? Any parts of the
>> repo which should be left out (Kexi?)?
>
> Applying full astyle is IMHO not OK, and even against efforts of
> everyone who keeps eye on proper coding style while doing code
> reviews.

Sorry, our current code base is a mess. I don't care about kexi, and I 
won't touch kexi. I won't touch any library except for pigment. But the 
mess we have with bracket placing, include styles, spaces around function 
arguments, initializer lists... It just needs cleaning up.

> Secondly, breaking git blame is unacceptable. Unlike file renames,
> there's no equivalent of --follow or ignoring whitespace while
> patching, it's a massive irreversible break in history.

We touch almost all the code when porting _anyway_. So this is the moment 
to clean up. History is less important than a clean base to work from.

But there's no reason to argue anyway, since your code and krita's code 
don't share much, if anything at all.
>
> People who try this would have to work with scripts like these [
> http://stackoverflow.com/questions/5098256/git-blame-prior-commits ]
>
> If someone cares enough, it's possible to edit history to fix some
> issues deep in entire history, disable git hooks, and push changes.
>

Boudewijn