On 07/31/2013 02:47 PM, Boudewijn Rempt wrote:
On Wednesday 31 July 2013 Jul 03:05:45 Sebastian Sauer wrote:
+2
May I suggest a two steps approach:
0) Get pending work needed for the port to master while still on Qt4.
Give them some time till problems are sorted out.
Yes -- that's wnat I'm doing in the krita-mvc-rempt branch, for instance. It's
a refactoring that makes KoPart no longer a KPart -- KoView is the only
KXMLGuiClient now.
Great :)
1) Port
Port to Qt5, keep kdelibs deps like they are, use e.g. those kdelibs
fake lib I have in coffice.
Yes -- that's what is now happening in the calligra-qt5-rempt branch. Following
friedrich's suggestion, I'm now focussing on libs, words, stage, sheets, active
(and krita, in my spare time...). But whenever something gets ported by perl,
everything gets changed.
- KMenu* m_viewModeMenu = new KMenu(this);
+ QMenu* m_viewModeMenu = new QMenu(this);
I wouldn't do such changes. Just use fake/kmenu.h and keep the diff
clean. Same with KLineEdit/QLineEdit, etc.
Golden rule: Not refactor. Never ever refactor while porting.
Right -- though sometimes porting feels like refactoring, when the guidelines say
"use Qt classes instead of K classes".
I am currently sort of stuck in sheets/localization, where there's a lot of
special stuff going on.
Hmpf. I solved all that in the last update for the coffice fake libs.
Sheets compiles AND runs fine on Android, Linux, Sailfish. Unfortunately
your fake-libs is >3 months old :/ So, we need to merge that over then.
Should I do?
That's not a rule I came up with but its very very true. Just not
refactor during a port. Never ever. Get things compiling, starting up,
core functionality working, voila.
2) Refactor.
Specific things will need refactoring the one or other way. This will
need much testing and has lots of potential for regressions. So, ideally
now the work should happen in master.
Hm... I wonder how difficult will that be when, for instance, we need to
refactor the plugin system?
Nope. The kdelibs plugin API is fine, the backend-logic we can replace
easily. Its done in the Coffice fake lib already. It reimplements that
kdelibs API using QPluginLoader. Coffice on desktop loads
calligra/filters and calligra/plugins on demand. We can use
QPluginLoader 1:1 with the current kdelibs plugin API what includes all
Calligra plugins.
Desktop-file's are gone, plugin-details need to be compiled in. I think
that's fine since a) we like to do so anyways using Json I think and b)
all Calligra plugins are in-tree and we still not promise API
compatibility (and doubt we will any time soon) so known whats there at
compile-time. During runtime libs can be loaded on demand using Qt's
plugin system. Let's not try to reinvent the wheel here.
In COffice all that happens static atm by creating and appending plugin
factories for every KPluginFactory (iirc that was the name) to
QPluginLoader::staticInstances(). That QPlugin-stuff allows easily to
turn that into plugins that are loaded at runtime what means somebody
can decide if a plugin is static compiled in or loadable at runtime with
just a compile-switch.
p.s. I would be willing to help on 1) and 2).
that would be awesome :-). calligra-qt5-rempt is the place to be for now :-)
Checking out, thanks.
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
