Porting to Qt5

[Sebastian Sauer]

Wow, wow. Fan-tas-tic work!

On 04/08/2013 04:49 PM, Boudewijn Rempt wrote:
> Hi,
>
> No doubt you've seen my qt5 porting branch. I was surprised at how far 
> I came, even though I was tempted to bang my head against my desk a 
> couple of times (especially over the Q_PRIVATE_SLOT thing -- while all 
> I had to do was change the moc includes in the cpp files from #include 
> <bla.moc> to #include <moc_bla.cpp>...) But it seems very doable indeed.

Q_PRIVATE_SLOTS is indeed a problem. For moc-includes: The fundamental 
problem here is that qmake uses a different moc filename layout then 
cmake. It cannot be changed in qmake to match to the cmake ones. Lukely 
this days we got automoc and that means in 99% of the cases we not need 
to include moc's any longer. Lesser code, lesser error-prune, more 
portable, yay :) An exception are classes like

test.h
class A : publci QObject
{
private:
class Private;
Private *d;
Q_PRIVATE_SLOT(d, SLOT(mySlot());
}

test.cpp
class A::Private
{
public:
     void mySlot() {}
};

cause here the moc needs to be included in test.cpp to know about the 
mySlot impl and be abel to call it.

Taken the very limited number of cases where we do that it may an idea 
to just not use Q_PRIVATE_SLOT.

>
> Here's my notes on how I want to proceed, after I get back from the 
> Libre Graphics Meeting:
>
> Past week, I've been looking into the most promising approach to port 
> Calligra to Qt5, and the effort needed to complete the task. Short 
> summary: it should be very doable.
>
> Approach
>
> The goal is to create a base Qt5-only port of Calligra (minus Kexi and 
> Plan for now) that can then optionally use KF5 libraries (like i18n). 
> My initial test used Qt 5.0.1, but I want to switch to Qt 5.1 as soon 
> as possible, so we can port to QSaveFile and other classes David Faure 
> added to Qt for 5.1

5.1 is/was scheduled for this month iirc. So, it should hit soon. Its 
also required for Android since Android-support got only introduced in 5.1.

>
> Steps
>
> * CMake: use extra-cmake-modules and a copy of relevant CMake modules 
> for KF5 plus some compatibility definitions to make it as easy as 
> possible to build Calligra with a minimum of changes. This is mostly 
> done.
>
> * kdelibs: add a shim "kofake" library that has enough of the KDE 
> headers and implementation to build. This mostly is ready, but there 
> is some stuff missing and currently libs/flake fails to build because 
> of missing stuff.

Oh, interesting. iirc it worked/works for me fine with all of flake.

>
> After everything builds we need some more steps to do a proper port:
>
> * Replace KPluginLoader with Qt5 plugin loading

This will give us static plugins for free. That means its super easy to 
just bundle multiple plugins into one or even compile everything static.

There is a limitation with plugins needing to inherit and declare 
interfaces. In coffice I worked around this. So, in fact Qt plugins are 
100% dynamic and can handle everything you throw at them.

>
> ** write a script to change all .desktop files to json
> ** write a script to change all plugins to add the json
> ** write a script to change all plugins from KDE plugins to Qt plugins
> ** change KoPluginLoader to build a database of the json of all 
> available plugins and support the minimal query set that we need for 
> calligra to load the right plugins at the right times
>
> I already have the calligra-kopluginloader-rempt where almost all 
> plugin loading is hidden behind the KoPluginLoader class.
>
> * Refactor calligra to no longer use kparts to load documents
> ** remove kparts and kxmlgui
> ** introduce the document, view, mainwindow base classes I started on 
> in the calligra-kopluginloader-rempt branch.
>
> * replace KUrl with QUrl
> * replace KMimeType with QMimeType handling
> * replace KSaveFile with QSaveFile
> * replace KStandardDirs and KComponentData with QStandardPaths
> * replace kconfig with qsettings

I am not sure if that's a good idea. KConfig has a few advantages in KDE 
land like configuration-overwrites, kiosk. Maybe we could just stick 
with KConfig and under the hood map to QSettings if needed? Or maybe use 
an own KoConfig that maps to either KConfig or QSettings?

The other such candidate is KAction vs QAction. KAction enables 
system-wide shortcuts. But then do we have use for that? Maybe yes for 
specific things like a "Create Screenshot" in Krita?

> * replace KSaveFile with QSaveFile
> * replace KTemporaryFile with QTemporaryFile
> * replace KTempDir with QTemporaryDir
> * replace KFileWidget/KFileDialog with QFileDialog (initial patch on 
> reviewboard)

There is no equivalent for KFileWidget in Qt and probably never will be. 
Well, QDirModel+QListView but that would miss any proper 
KDE-integration. But then I doubt there are much users of KFileWidget in 
Calligra.

> * port all tests from qtest_kde.h to QtTest or QtTestWidgets
> * KApplication to QApplication

I am not sure about the KApplication/QApplication case either. KApp 
still provides some additional functionality iirc. Could need some 
investigation.

> * ....
>
> (all the things recommended in the KF5 porting file -- much of it can 
> be done with simple scripts).
>
> * Get rid of kofake completely by either using the Qt equivalent of 
> classes (most cases), or add optional dependencies on KF5 tier1 
> libraries.
>
> * Start hacking on graphics tablet support in Qt5... I guess.

:-)

>
> Boudewijn
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>