Jump to content

Digikam/CodingSprint2014: Difference between revisions

From KDE Community Wiki
Line 8: Line 8:


Note: all port code must be stored in dedicated "frameworks" git branch for each project.
Note: all port code must be stored in dedicated "frameworks" git branch for each project.
Porting to KF5 is divided in 3 stages:
1/ Change Cmake files. some Laurent scripts do this stuff. We use now
ECM scripts collection from KDE core to manage dependencies and report on the
console. Some macros disappear, and are replaced by new ones. For this
job, it's recommended to look well all done in Cmake files from libkexiv2
and libkdcraw already ported and polished.
2/ Port c++ code using KDE4Support. This include older classes from Qt4
and KDE4 to make transition faster. This will help to have quickly a
code compilable, but this will generate a lots of deprecated warnings.
First regression tests must be done at this stage to see if nothing is broken.
3/ Port c++ code to pure Qt5. The goal of KF5 is to reduce KDELibs
fingerprint everywhere, when it's possible. Qt API will be used in
priority against KF5 API. But sometime, this will be not possible as
well, without big changes. A lot of KDE API have migrated to Qt5
(as for ex : KUrl -> QUrl and kDebug ->qDebug). It's sound like KDELibs
will become an incubator for new implementations which will move later
to Qt. Also, to have the most of code using pure Qt5 will simplify
future transitions more easy to do.


{| border="1" class="wikitable"
{| border="1" class="wikitable"
Line 99: Line 77:
|
|
|}
|}
=== Recommendations ===
Porting to KF5 is divided in 3 stages:
1/ Change Cmake files. some Laurent scripts do this stuff. We use now
ECM scripts collection from KDE core to manage dependencies and report on the
console. Some macros disappear, and are replaced by new ones. For this
job, it's recommended to look well all done in Cmake files from libkexiv2
and libkdcraw already ported and polished.
2/ Port c++ code using KDE4Support. This include older classes from Qt4
and KDE4 to make transition faster. This will help to have quickly a
code compilable, but this will generate a lots of deprecated warnings.
First regression tests must be done at this stage to see if nothing is broken.
3/ Port c++ code to pure Qt5. The goal of KF5 is to reduce KDELibs
fingerprint everywhere, when it's possible. Qt API will be used in
priority against KF5 API. But sometime, this will be not possible as
well, without big changes. A lot of KDE API have migrated to Qt5
(as for ex : KUrl -> QUrl and kDebug ->qDebug). It's sound like KDELibs
will become an incubator for new implementations which will move later
to Qt. Also, to have the most of code using pure Qt5 will simplify
future transitions more easy to do.


=== Common changes to port code ===
=== Common changes to port code ===

Revision as of 08:27, 19 November 2014

KDE Graphics Coding Sprint 2014

The KDE Graphics coding sprint 2014 will take place at Berlin, Germany, from november 14h to 16th 2014.

KDE Framework Port

KF5/Qt5 Status

Note: all port code must be stored in dedicated "frameworks" git branch for each project.

Component Project Page Status KDE4Support Who Remarks
libkexiv2 link done yes Gilles, Laurent
libkdcraw link done yes Gilles, Laurent, Veaceslav
  • ThreadWeaver and Solid dependencies removed.
  • RActionThreadBase is ported to QThreadPool + QRunnable API instead ThreadWeaver.
  • In second time, KIntNumInput and KDoubleNumInput are deprecated, and we can plan to use Krita Int and Double input widgets to replace RNumInput and add reset button. See bug #284216 for details.
libkipi link under progress yes Gilles, Laurent, Mohamed
libkface link under progress yes Gilles, Laurent
libkgeomap link under progress yes Gilles, Laurent
Software Compilation link todo
digiKam link todo
Kipi-plugins link todo

Recommendations

Porting to KF5 is divided in 3 stages:

1/ Change Cmake files. some Laurent scripts do this stuff. We use now ECM scripts collection from KDE core to manage dependencies and report on the console. Some macros disappear, and are replaced by new ones. For this job, it's recommended to look well all done in Cmake files from libkexiv2 and libkdcraw already ported and polished.

2/ Port c++ code using KDE4Support. This include older classes from Qt4 and KDE4 to make transition faster. This will help to have quickly a code compilable, but this will generate a lots of deprecated warnings. First regression tests must be done at this stage to see if nothing is broken.

3/ Port c++ code to pure Qt5. The goal of KF5 is to reduce KDELibs fingerprint everywhere, when it's possible. Qt API will be used in priority against KF5 API. But sometime, this will be not possible as well, without big changes. A lot of KDE API have migrated to Qt5 (as for ex : KUrl -> QUrl and kDebug ->qDebug). It's sound like KDELibs will become an incubator for new implementations which will move later to Qt. Also, to have the most of code using pure Qt5 will simplify future transitions more easy to do.

Common changes to port code

  • Change all #include "foo.moc" as #include "foo.h" to prevent compilation errors with Qt5.

Link to documentation to port code

Scripts to port code

Laurent Montel has written scripts to port CMake and C++ code to KF5/Qt5 and remove kdelibs4support dependency. There are available in this repository.

Scripts must be applied in this order, with a test compilation between each one :

  • Full safe scripts :
    • convert-to-k4aboutdata.pl (first one to apply, this help to compile)
    • adapt_cmakelists_file.pl (to convert CMake scripts, but code must don't be capititalized)
    • remove-kde4support.pl
    • convert-kicon.pl
    • convert-kmenu.pl
    • convert-kshortcut.pl
    • convert-kcolordialog.pl
    • convert-klistwidget.pl
    • convert-kmd5.pl
    • convert-kmenubar.pl
    • convert-ksplashscreen.pl
    • convert-kdebug.pl
  • Less safe scripts :
    • convert-kintnuminput.pl
    • convert-kintspinbox.pl
    • convert-ktextbrowser.pl
    • convert-kfontcombobox.pl
  • Scripts which need to check in-deep all changes :
    • convert-kvbox.pl
    • convert-kdialog.pl
    • convert-kcmdlineargs.pl
    • convert-kdebug-with-argument.sh (this one change kDebug(1556) en qCDebug with some info after to convert)
    • convert-kmimetype.pl
  • Last scripts to apply :
    • clean-forward-declaration.sh (remove forward declaration, to do when all compile fine)
    • clean-includes.sh (try to remove not used includes, not safe to 100%)
    • port_to_autogenerate_export_header.sh (convert to new signal/slot API, not safe to 100%)

Image Editor Model/View Fixes and Finalization

CANVAS : full image dimensions not shown when not viewing at 100% zoom level

CANVAS : image is displayed with wrong magnification after crop

CANVAS : image shifts position in mouse-over mode when changing between Before and After

CANVAS : mouse-over preview mode does not work

CANVAS : unable to zoom out to less than fit to window

Unable to crop due to image corruption into canvas with not X11 based computers

Import Tool Reports Review and Fixes

Database Reports Review and Fixes

Coding Sprint Notes

Next major task is to port digiKam to Qt5. Approx. 10% is already ported by Gilles. Objectives for this coding sprint:

  • Specify timeline for porting digiKam
  • Identify priorities (what should be ported first)
  • Delegate porting tasks to developers (who does what)


Shourya Singh Gupta works on implementing the Kipi tools functionality in the Batch Queue Manager (Tools Settings).

Marcel Wiesweg works on memory consumption in database and the bug with JPEG (and RAW) image preview on high-resolution screens. Also see https://bugs.kde.org/show_bug.cgi?id=205776

He work also to complete the Removable collection support. The goal is to show thumbnails from disconnected media, but not editable as well. A feedback to the user is provided to indicate that items and collection are not available, but users can continue to search and preview collection through database. See bugs https://bugs.kde.org/show_bug.cgi?id=191494 and https://bugs.kde.org/show_bug.cgi?id=114539.

MySQL support is now disabled by default because it's not fully functional and still experimental. MySQL support still fully available of course, but as an optional feature.

Gilles has polished whole libkgeomap public API to be ready for KF5 port. A lots of changes have been applied to reduce binary compatibility issues, especially, if library will be moved somewhere in KDE core to be more easily used by another project as KPhotoAlbum, like it have been done recently about libkface.