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