Porting to Qt5

[Sebastian Sauer]

On 04/08/2013 06:05 PM, Boudewijn Rempt wrote:
> Well, I'm fine with having moc_bla.cpp includes where Q_PRIVATE_SLOT 
> is used. I don't think there's any real problem there.

Its a problem when somebody switches cmake<=>qmake (both directions) 
cause of there moc filename incompatibilities. Anyhow, there are work 
arounds like I used at the bottom of calligra/coffice/common.pri. So, 
not unsolvable but just not nice. Anyhow, really not that important atm.

>
>>> * 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.
>
> These are the linking errors I currently get:
>
> Linking CXX shared library libflake.so
> CMakeFiles/flake.dir/KoCanvasControllerWidget.cpp.o: In function 
> `qobject_cast<QGLWidget*>':
> /usr/include/QtCore/qobject.h:473: undefined reference to 
> `QGLWidget::staticMetaObject'

Linking to QtOpenGL needed?

> CMakeFiles/flake.dir/KoToolManager_p.cpp.o: In function 
> `ToolAction::qt_metacall(QMetaObject::Call, int, void**)':
> /home/boud/kde/build/calligra/libs/flake/moc_KoToolManager_p.cpp:334: 
> undefined reference to `KAction::qt_metacall(QMetaObject::Call, int, 
> void**)'

...

> make[1]: *** [libs/flake/CMakeFiles/flake.dir/all] Error 2
> make: *** [all] Error 2
> makeobj[0]: Leaving directory `/home/boud/kde/build/calligra/libs/flake'
> boud at linux-pb1y:~/kde/build/calligra/libs/flake>

QT4_WRAP_CPP for header-only's with Q_OBJECT?
qmake not needs that cause I added all of them to HEADERS.

>>> * 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 latter would be best, I guess. Though kiosk seems dead anyway.

It should still work except somebody broke it last years. But yes, 
kdelibs always had missing man-power :/

>
>> 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?
>
> Nope -- nothing like that. For KAction, my biggest beef is that it is 
> too smart. For krita at least, I want to handle shortcut management 
> myself, because shortcuts are used for more than QAction-based actions

I see. Then indeed there is no reason I can think of.

>
>>
>>> * 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
>
> This is the full set:
>
> kexi/main/startup/KexiStartupDialog.cpp
> kexi/main/startup/KexiStartupFileHandler.cpp
> kexi/widget/KexiConnectionSelectorWidget.cpp
> kexi/widget/KexiFileWidget.cpp
> krita/ui/kis_layer_manager.cc
> libs/kokross/KoScriptManagerAdd.cpp
> libs/main/KoExistingDocumentPane.cpp
> libs/main/KoMainWindow.cpp
> plugins/pictureshape/PictureShapeConfigWidget.cpp
> plugins/vectorshape/VectorShapeConfigWidget.cpp
> plugins/videoshape/SelectVideoWidget.cpp
>
> But Yue has already started on it.

Great!

>
>>> * 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.
>
> That's what the porting guidelines recommend:
>
> Changes in kdeui
>
>     KApplication/KUniqueApplication: use QApplication instead, but 
> make sure to:
>         Call QCoreApplication::setApplicationName("...")
>         Call QCoreApplication::setOrganizationDomain("kde.org")
>         Call QApplication::setApplicationDisplayName(i18n("...")) for 
> GUI programs
>         Use KDBusService for DBus registration, and optional "unique" 
> behavior

Ah. I should start reading them. Okeli, thanks.