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