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

[Friedrich W. H. Kossebau]

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)

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

> 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.

> > 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