Calligra 3.0 for Qt 5.1?

[Sebastian Sauer]

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.