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.
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
