Calligra 3.0 for Qt 5.1?

Sebastian Sauer mail at dipe.org
Wed Jul 31 15:07:48 BST 2013


On 07/31/2013 06:22 PM, Boudewijn Rempt wrote:
> 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?

Nah, np.

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

Yep, seen. I already ported the changes I did since then over. Updating 
Qt/setup to compile the branch. May take some time.

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

If its the code in staging/kservice/plugin then it seems to drag 
kservice in which drags in kbuildsycoca. I don't think that's needed.

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

Will land some patches related to that that where missing in your branch 
soon.




More information about the calligra-devel mailing list