Porting to Qt4

 started: jstaniek, 4 june 2005

Table of Contents    Subtasks    Discussion    Rules for porting    Missing configure checks    Status    General hints    Useful links

Subtasks

• Porting to Qt4/Core
• Porting to Qt4/KexiDB
• Porting to Qt4/MainWindow

Discussion

jstaniek: I'd like to stick with Qt3 for quite a long time, but proposing out db libraries for inclusion into kdelibs, kproperty, etc. My proposal is to stick with Qt3 as primary developemnt base, because for about 2 or even 3 years linux distros will have Qt3 environment installed together with Qt4, so we're not forced to make a jump.

Initially, within Kexi we're not so LARGE grantee of Qt4, regarding to its improved drawing features; maybe with except for reports, but that's KoText/KPrinter's task. Let's develop things in portable fashion, using Qt4 guidelines: I've heard somebody published them, eg. "don't use QVBox but QVBoxLayout instead" etc. One thing we may want to reconsider i nthe future is to reuse simplified KMdi; you know how current one is broken :)

ccpasteur: at least I'll wait until kdebase is completely ported and tested

sebsauer: besides maybe some speed-improvments I am able to see only 2 real reasons to port to Qt4;

• KDE4 will be based on Qt4. So, some day in near future it may a more common KDE-task to port whole svn to get it at least compiled with Qt4. KOffice would be affected as well as Kexi. So, even if we don't do the work by our own maybe we'll see some commit's to Kexi to get it at least compiled with Qt4.
• We've a Qt4 GPL'd Windows-version. This would e.g. allow me to start porting of Kross to windows...

Rules for porting

• For now it's not recommended to fix "deprecated" warnings like QString::latin1(). Why? Because if we do this, it's so much harder to do commits to 1.6 and 2.0 branches in parallel: you'll lose all the context of diff -u. These fixes can be made after KOffice 1.6 development finishes.
• Configure detection is made by adding Find*.cmake files in koffice/cmake/modules. For example: FindPostgreSQL.cmake.
• Use QString::toString() instead QString::asString(). The latter is obsolete and can cause a crash. All the Kexi source code already uses toString().
• use 'uic3 -convert' to convert .ui files to Qt4 format; if there are problems like invalid <kintnuminput.h> include, read this solution
• add <author> and <comment> (with LGPL license) to all the .ui files
• use i18n(<text>, <arg>, <arg>) instead of i18n(<text>).arg(<arg>).arg(<arg>);
  • use I18N_NOOP whenever %1, %2, ... arguments have to be set delayed; e.g. in KexiPart::i18nMessage() implementation, I18N_NOOP should be used.
• switch from int to QFlags wherever possible
• use K_GLOBAL_STATIC instead of KStaticDeleter
• Use KLineEdit::setClearButtonShown(true) on most line edits; do the same for comboboxes and remove clear button explicitly added in Kexi 1.x.
• Be careful when repalcing the old hack like QDict<Foo> with QHash<QString,Foo*>. If you expect to have multiple values for the same key, use QHash::insertMulti() instead of QHash::insert(). Example case: criterias variable in KexiQueryDesignerGuiEditor::showFieldsOrRelationsForQueryInternal()

Missing configure checks

Checks must be coded for cmake. Previously were defined in configure.in.in files. Known missing checks:

• kexi_LIB_READLINE
• SQLITE_PTR_SZ in 3rdparty/

Status

Possible flags:

• [] - untouched
• [DIFF PERFORMED] - diff against 1.6 branch has been performed to make sure there are no missing merges
• [IN PROGRESS] - we're porting this directory
• [COMPILES] - compiles but was not fully tested at runtime (or at all)
• [DONE] - runs well: all classes are tested (used elsewhere)
• [DONE-KDE4] - like [DONE] but Qt3Support, KDE3Support libraries are not used

Status:

• [DONE] 3rdparty
• [COMPILES] libs/koproperty
• [COMPILES] libs/kross
• [DONE] kexiutils
• [DONE] kexidb
• [DONE] kexidb/drivers/sqlite
• [DONE] kexidb/drivers/sqlite2
• [DONE] kexidb/drivers/mySQL
• [DONE] kexidb/drivers/pqxx
• [DONE] tests/newapi
• [COMPILES] core (largely ifdef'd)
• [COMPILES] widget/utils (except kexidatetimeformatter.cpp and kexigradientwidget.cpp)
• [COMPILES] widget/tableview
• [COMPILES] widget
• [COMPILES] widget/relations
• [COMPILES] formeditor
• [COMPILES] main
• [COMPILES] main/startup
• [] main/printing (later)
• [COMPILES] migration
• [COMPILES] migration/mysql
• [COMPILES] migration/pqxx
• [COMPILES] migration/mdb (imported from kdenonbeta/keximdb)
• [COMPILES] plugins/tables
• [COMPILES] plugins/queries
• [COMPILES] plugins/forms
• [COMPILES] plugins/forms/widgets
• [COMPILES] plugins/relations
• [COMPILES] plugins/migration
• [COMPILES] plugins/importexport/csv
• plugins/scripting (todo: dipesh)
• plugins/macros/lib (todo: dipesh)
• plugins/macros (todo: dipesh)

General hints

• replace virtual void show() with virtual void showEvent( QShowEvent * )
• when functions like KFileDialog::getOpenFileName() are used, port from using ":SettingName" to kfiledialog:///SettingName
• use bool KColumnsView::event( QEvent *Event ) with event->type() == QEvent::StyleChange instead of nonexisting void QWidget::styleChange ( QStyle & oldStyle );
• we are no longer using unportable '-include' compiler option; #include <kexi_export.h> is needed in every header lowest-level header to get *_EXPORT defines
• Setting compile-time options are now available through koffice/kexi/CMakeSettings.txt. Create the file on yourself and put your defines like ADD_DEFINITIONS(-DKEXI_DEBUG_GUI ), and these will be used globally by the build process.
• To increase portability, "-include $(top_srcdir)/kexi/kexi_global.h" CXX global compilation flag is not specified (this was defined for Kexi 1.x in Makefile.global), so you need to insert #include <kexi_export.h> for any top-level .h file or even #include <kexi_global.h> if you want use macros like 'kexidbg'.
• Icons for mimetypes are no longer defined in .desktop files, so e.g. for application/x-kexiproject-shortcut mimetype, instead of "kexiproject_shortcut" icon, we have to use "application-x-kexiproject-shortcut" icon (so the name is based on mimetype name).

Useful links

• CMake Wiki, in particular CMake_HowToDoPlatformCheck is useful as we need some compile-time checks, e.g. for MySQL client lib.