| Summary: | Port digiKam to KF5 and Qt5 | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Andi Clemens <andi.clemens> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alinm.elena, anaselli, aspotashev, benjamin.girault, caulier.gilles, geow812, marcel.wiesweg, mohammed.ahmed.anwer, montel, wazery |
| Priority: | NOR | ||
| Version: | 4.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 5.0.0 | |
| Sentry Crash Report: | |||
| Attachments: | patch to drop QT3Support dependency | ||
|
Description
Andi Clemens
2013-03-30 10:38:13 UTC
This is just a reminder bug entry, that we might have problems building on Qt5 systems. No need to look into the bug right now, I will switch to Qt4 anyway because a lot of stuff doesn't seem to work here. Do you have a trace ? Also, it think Qt3Support classes are dropped. It still 3 sub classes based on Q3ScroolView that are proposed to port to Qt4 model with GoSC 2013 Gilles No I have no trace since cmake itself doesn't work. But I know from other projects and private code that Qt5 is a little bit incompatible with Qt4, so we might need to change our code anyway. There is a migration tool, but this doesn't always work. I have an archlinux box, with qt5-base installed (no other qt5 packages), and qt4 also. CMake runs successfully, so as make (not finished though). I had a problem with an AUR package a few weeks ago which was caused by some changes introduced by QT5 in the system leading to QT4 not being detected correctly (basically QT5 has been made the default instead of QT4, I'm not sure if it's still the case though). The solution was to add the option "-DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4" to the cmake command line. I know that this doesn't change the problem that any QT4 program will most likely not compile with QT5 libraries, but at least, this should help compiling digiKam on an archlinux with both versions of QT. Ok, I will try this solution.. thanks Andi, Qt5 compatibility must not be a problem with all shared libs managed by digiKam team and published through digiKam Software Compilation. This must be the same with kipi-plugins, where at least some few adaptations must be done... The most important changes must be done into digiKam core where some classes based on Q3ScrollView exist yet... 2 GOsC 2013 projects completed this summer developed in separated branches must complete the job : http://community.kde.org/Digikam/GSoC2013#Port_Image_digiKam_Editor_Canvas_Classes_to_Qt4_Model.2FView http://community.kde.org/Digikam/GSoC2013#Port_Showfoto_Thumb_bar_to_Qt4_Model.2FView These branches must be merged to git/master after 4.0.0-beta1... Gilles Caulier Yiou, I just synchronized Yiou branch "gsoc2013-editorcanvas" with master for a future merge back later. There is no conflict : http://commits.kde.org/digikam/4aba11d730b22c70a5f4162c3214ec932ab54f9a Mohamed, Islam, About "gsoc2013-thumbbar-mv", there are few conflicts to do the same. Can you fix it please ? Thanks in advance Gilles Caulier Created attachment 84510 [details]
patch to drop QT3Support dependency
Just to complete this file, when Image Editor Canvas project will be completed, this patch work fine. Whole digiKam compile without Qt3support classes.
This simple patch can be only applied against "remotes/origin/gsoc2013-editorcanvas" branch managed by Yiou Wang...
Gilles Caulier
Notes to port code from KDE4 to KDE5 : http://community.kde.org/Frameworks/Porting_Notes Gilles Caulier Git commit e0559f941c0c4f407ca2c2df2e00077c53fb8736 by Yiou Wang. Committed on 29/01/2014 at 23:11. Pushed by yiouwang into branch 'master'. Apply patch remove qt3support and fix 9/ rubberitem problem M +2 -2 digikam/CMakeLists.txt M +1 -1 imageplugins/color/CMakeLists.txt M +1 -1 imageplugins/decorate/CMakeLists.txt M +1 -1 imageplugins/enhance/CMakeLists.txt M +1 -1 imageplugins/filters/CMakeLists.txt M +1 -1 imageplugins/transform/CMakeLists.txt M +1 -2 utilities/imageeditor/widgets/canvas.cpp http://commits.kde.org/digikam/e0559f941c0c4f407ca2c2df2e00077c53fb8736 Hi all, Yiou Wang has merged development branch about model/view port of image editor canvas in master and has applied my patch to drop Qt3 support dependency. Code from master is fully ready to be tested and patched to support Qt5 API. If someone has Qt5 development package installed and can compile it to test, lets' me hear... Gilles Caulier Gilles, mageia has qt5 either in mga3 and into the incoming mga4, so i could. Write me in private to explain which tests you need, and eventually how to. Next week i'm out of office, so i have no time, but i could try this week-end. Hi Angelo, I see on my computer that Qt5 devel packages are here. But has Qt4 is default devel packages, how to force digiKam compilation rules to use Qt5 instead Qt4 ? I'm sure that some CMake switch must be passed at configure time, but which one ? I know that Nicolas Lécureuil do it for KDElibs, but i don't have any others information.... The goal of course is to try to compile with Qt5. Some errors will come and patches must be created to fix it. Gilles are we switching to qt5 or do we have to compile for both? I will check how to force qt5 compilation, it should not that hard, if cmake macros work correctly, i hope. Angelo, It's a transition stage of course. Qt4 and Qt5 must be supported at the same time until Qt4 will dropped in the future... Gilles Laurent, If you have 5 minutes and if you have a computer with KDE5 and Qt5 API installed, can you take a look if digiKam, kipi-plugins, and shared libs compile fine ? Thanks in advance Gilles Caulier Port to KDE5 is not direct :) It's not harder as kde3->kde4 but there is a lot of changes to do. It will easier to port to qt5/kde5 as you don't have qt3support but it will not build directly. We need to port it before. For me better to wait kf5-beta1 for the moment it's TP Wait a little before to port to kde5/QT5 And we need to adapt cmake too etc. so it will not compile with kde5/Qt5 tomorrow Laurent, A transition stage will possible or not, as both KDE4 and KDE5 will supported by digiKam ? Or it will be better to switch directly whole digiKam & co to KDE5/Qt5 and forget KDE4/Qt4 ? Gilles KDE framworks 5 are unfinished at the moment. We should take care not to port before the underlying platform is stable. We certainly do not want to maintain something which has #ifdefs at multiple places to support both KDE4 and KDE5. For me migrate to KF5 and not keep kde4 + kde5 it's not really possible. digikam 5.0 :) Libkexiv2 and libkdcraw have been ported to KF5 and code are stored in separate Git branches named "frameworks" : https://projects.kde.org/projects/kde/kdegraphics/libs/libkdcraw/repository/show?rev=frameworks https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/show?rev=framework Gilles Caulier Laurent, I just seen that libkexiv2 has 2 branches : "framework" and "frameworks" The first one is code ported to KF5, the second one is KDE4 version. If i follow others project, the right branch name to use is "frameworks" for KF5 port. So, current libkexiv2 branch "frameworks" must be removed and "framework" must be renamed as "frameworks". Right ? Gilles Hi Gilles, what is the status of this? I did a rapid scan and looks to me all the major deps for digikam are qt5/kf5 ready. Alin seems i answered mysefl https://techbase.kde.org/Projects/Digikam/CodingSprint2014#KDE_Framework_Port Port of digiKam to KF5 start to be runnable. Not yet complete sure. https://www.flickr.com/photos/digikam/15509459184/in/pool-digikam-labs Gilles Caulier |