From calligra-devel Sat Mar 30 07:07:42 2013 From: Sebastian Sauer Date: Sat, 30 Mar 2013 07:07:42 +0000 To: calligra-devel Subject: Re: Rename Coffice? Message-Id: <51568F3E.9050506 () dipe ! org> X-MARC-Message: https://marc.info/?l=calligra-devel&m=136463032014439 On 03/29/2013 05:31 PM, Boudewijn Rempt wrote: > On Thursday 28 March 2013 Mar 18:20:01 Thorsten Zachmann wrote: >> Hello Sebastian, >> >> On Thursday 28 March 2013 18:10:35 Sebastian Sauer wrote: >>> * Or alternatively port Calligra to Qt5. >> boud is working on that and in the same time trying to reduce the kde >> dependencies where needed and remove the usage of kparts. >> >> Maybe you can join forces. > Right now, I'm still in the explorative stages, but I hope to get some ways over Easter. > What do you plan there re kdelibs/kdeframeworks? For cmake imho the easiest thing would be something similar to what I did at: https://github.com/sebsauer/Charm/commit/5106c0385cabc27bb5a65f64321e3bf267fd7a32 Means introduce own QT_* / KDE_* / CALLIGRA_* cmake variables that are then used everywhere and depending on the Qt/kde version compiled against set with Qt4/Qt5 vs kdelibs4/kdeframework variables. I must admit my knowledge about kdeframeworks/kdelibs@Qt5 is so outdated that its not existing. So, no idea how compatible/doable that is, what the state there is, etc. The advantage I see here is that the current Qt4+kdelibs4 solution would keep working and the chunk of work to make Qt5+kdeframeworks working could be split and done step by step (e.g. library by library) rather then with one big patch/commit and switch needed + the result would work fine with Qt4/kdelibs and Qt5/kdeframeworks what may interesting at least for some time till all was ported/tested and is releasable with Qt5/kdeframeworks. So, it would allow a soft-switch with work going in chunks into master while keeping things working as there are. I think that, the cmake work, is indeed the by far biggest part of work. Second may probably changed kdelibs API/includes/library-names. Personally I found the Qt4=>Qt5 switch rather easy and straith-forward. Usually its mostly changing some includes here and there and some "#if QT_VERSION < 0x050000 .... #ELSE .... #ENDIF" cases where API was changed. The equivalent to the cmake Qt4/Qt5-link above for compile+link with Qt4/Qt5 (to give an impression) is: https://github.com/sebsauer/Charm/commit/b3a2bd17dfaffcb24e0c3e25520cf473df815a3f From my personal experience (also based on kde3/qt3=>kde4/qt4) such a soft switch is worth diamonds. It also has the advantage to fullfit the golden porting rule of "never refactor while porting" in that it enables clear separation/testing/splitting of work done. _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel