Calligra 3.0 for Qt 5.1?

[Boudewijn Rempt]

On Wed, 31 Jul 2013, Sebastian Sauer wrote:

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

Hm, that's a bit too late now -- I already did almost all of that :-(. 
Should we start again?

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

Yes -- with some caveats, I probably build more than you do, so I had some 
additions to fakes -- including the addition of exports.

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

Ah -- I was thinking of using Sebastian Kugler's work to automatically 
create the json from desktop files and so on. Or is that more or less the 
same?

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

That sounds pretty good.

>
>>> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>