RFC: plan for starting the Qt5/KF5 port

[Boudewijn Rempt]

On Wed, 25 Feb 2015, Friedrich W. H. Kossebau 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.
>
> 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)


http://en.wikipedia.org/wiki/Pragma_once#Portability -- it really should 
be fine. And we've had dozens of errors with header guards over time, to 
it would be good to use a more fail-safe method of making sure headers get 
included only once.

I guess nobody else uses it because of lingering ideas that gcc doesn't 
support it, but gcc on CentOS 6.4 is 4.something, so that's fine.

>
>> * 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?)?

This is a whole list, and parts of it are really a good thing, like fixing 
the includes. We don't want, absolutely not, QModule/QClass style includes 
while porting. That's such a disaster. (And it was a bad idea to begin 
with, just makework -- why should anyone need to remember which module a 
Qt class comes from?) I did something similar with the previous Qt5 port, 
as well as making sure that all our kde includes were consistent.

Other parts, well, it depends on what I end up porting. I need libs, 
plugins and krita and parts of karbon. I won't touch any other 
application.

>
>> For the rest of the scripts, I intend to use them on pigment and krita at
>> least.
>
> Noted.
>
>> There are also some things that might need more thinking beforehand:
>> 
>> * plugin loading. This changed a lot in KF5. We already didn't use the
>> sycoca anymore for loading plugins, and we probably can, for now, still
>> use the .desktop file system to find plugins. However, we should check the
>> old Qt5 porting branch and see if we can re-use its plugin loader. That
>> uses the new Qt5 plugin+json combination already. Check KoJsonTrader.cpp
>
> Any takers? Noted.
>
>> * That branch also contains some patches for Qt regressions (like
>> bcd822eac52e09b6bf7a4c9fe293c9b3234a6486 or
>> a5361d299b3991f9414466ad9d0c83537e6f2778), so it might be useful to refer
>> to it while porting the libs, Words, Sheets and Stage.
>
> Noted.
>
>> >> *The dep tree of products can be either seen from content of
>> >> CalligraProducts.cmake or in a picture by using the generated
>> >> "product_deps.dot" in the toplevel dir:
>> >> dot -Tsvg product_deps.dot > product_deps.svg
>> >> or
>> >> dot -Tpng product_deps.dot > product_deps.png
>> 
>> That isn't in there already, right?
>
> Should be, both master and 2.9 branch. Toplevel _build_ dir, sorry, was not 
> precise enough.

Ah, right!

>
>> > Any set of tags can be configured. Feel free to append invent tags
>> > like KRITA3 or KRITAQT5.
>> > So you can filter the tags easier in your area of interest, make the code
>> > navigation easier.
>> > I am sure vim/emacs users have their habits and the tags can work for
>> > them as well.
>> > 
>> >> Reasoning:
>> >> ----------
>> >> Calligra has over 4 M lines (claims openhub.net, not counted myself), so
>> >> expecting one person to do all the initial porting would be quite some
>> >> burden to that. Also is noone expert in all code.
>> 
>> Sloccount counts 1,771,776:
>
> Okay :) 
>
>> >> Comments, please.
>> 
>> After 3.0, for 3.1, I want to split up our repository. It's just getting
>> too unwieldy to manage. That's as far as my thinking has gone :-)
>
> Noted.
>
> Cheers
> Friedrich
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop