Re: Interesting issue for kde-baseapps, Jenkins kdesrc-build, proposed solution
Other alternatives include splitting kate up in the various library/runtime- support/application components but that's a lot of extra work for what is really just a kde-projects problem. Does anyone have objections to the sysadmins realigning the 3 git modules in question? (And if so, I'd appreciate ideas for better ways to fix). Hi, I would have no problem with moving kate.git around, splitting is IMHO a pain for later developing on it, as all parts are tightly coupled anyway. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 2:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 2:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? - Andrea Scarpino On March 11, 2013, 3:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 3:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 6:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? Stephen Kelly wrote: No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 I don't want to remove the 'qmake' word from the FindQt4.cmake file, but ATM that file looks for: qmake qmake4 qmake-qt4 (and so on) in this order. Why not using this one instead? qmake4 qmake-qt4 qmake... - Andrea --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 3:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 3:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? Stephen Kelly wrote: No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 Andrea Scarpino wrote: I don't want to remove the 'qmake' word from the FindQt4.cmake file, but ATM that file looks for: qmake qmake4 qmake-qt4 (and so on) in this order. Why not using this one instead? qmake4 qmake-qt4 qmake... Did you follow the link I sent to the thread on the cmake list? - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 2:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 2:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 6:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? Stephen Kelly wrote: No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 Andrea Scarpino wrote: I don't want to remove the 'qmake' word from the FindQt4.cmake file, but ATM that file looks for: qmake qmake4 qmake-qt4 (and so on) in this order. Why not using this one instead? qmake4 qmake-qt4 qmake... Stephen Kelly wrote: Did you follow the link I sent to the thread on the cmake list? No, I missed the reply in the second link in the thread you linked. Ok, I see your point now. I'll think about it. - Andrea --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 3:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 3:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Review Request 109421: Support custom providers in the GHNS upload dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109421/ --- Review request for kdelibs. Description --- The download dialog correctly takes a custom providers .xml file, as can be specified in the .knsrc file, into account; however the upload dialog just ignored this option until now. This patch intends to fix that behavior. Nothing should change if you don't have a custom ProvidersUrl= in your .knsrc file. Diffs - knewstuff/knewstuff3/upload/atticahelper.h 4e538d3 knewstuff/knewstuff3/upload/atticahelper.cpp 735910f knewstuff/knewstuff3/uploaddialog.cpp 70a8568 knewstuff/knewstuff3/uploaddialog_p.h 50f8dd9 Diff: http://git.reviewboard.kde.org/r/109421/diff/ Testing --- The new provider is correctly being listed in the dropdown list of the first page of the dialog. If the custom provider is selected, the program tries to establish a connection to that provider. However, I could not test it any further because I don't have a working provider server... yet. File Attachments a screenshot of the dialog showing two providers, one of them loaded from the XML file specified in .knsrc http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png Thanks, Sven Brauch
Re: Review Request 109404: Give more precedence to qmake executable names that specify the version
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote: I was quite clear: qmake must point by default to Qt 4 if Qt 4 present. While qtchooser sounds like a great solution to handle this, it only adds more confusion from a packager view: we cannot have N differents configurations for qt when the users install our packages: qmake points to qt5, no matter which configuration the user did setup for qtchooser. Also, every binary points to the latest version in Arch (e.g. python points to python3 not python2) However all this discussion isn't related to Arch itself: I think that binaries with specific version takes precedence, don't they? Stephen Kelly wrote: No, you also need to account for self-built Qt, which will also result in a binary called 'qmake'. http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623 Andrea Scarpino wrote: I don't want to remove the 'qmake' word from the FindQt4.cmake file, but ATM that file looks for: qmake qmake4 qmake-qt4 (and so on) in this order. Why not using this one instead? qmake4 qmake-qt4 qmake... Stephen Kelly wrote: Did you follow the link I sent to the thread on the cmake list? Andrea Scarpino wrote: No, I missed the reply in the second link in the thread you linked. Ok, I see your point now. I'll think about it. It's very simple: if you're going to make an unsupported installation, KDE should feel quite comfortable by not supporting your distribution. CMake can find Qt 5 without qmake, that's why it's recommended that qmake point to Qt 4's qmake. For users running qmake manually, the Qt documentation should explain how to run qmake -qt5 (yes, with the space). Anyway, why is this an issue at all? Why doesn't FindQt4.cmake discard the Qt 5 qmake if the version number is wrong? Shouldn't it try again with a new executable name? - Thiago --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/#review28931 --- On March 11, 2013, 2:29 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109404/ --- (Updated March 11, 2013, 2:29 a.m.) Review request for Build System, kdelibs, David Faure, Alexander Neundorf, and Andrea Scarpino. Description --- Recently ArchLinux decided to ship Qt5 and they did so by making qmake point to qmake-qt5 and adding qmake-qt4. With this patch, we look first for the executables that specify the version number and then the more generic ones. Diffs - cmake/modules/FindQt4.cmake 6db944f Diff: http://git.reviewboard.kde.org/r/109404/diff/ Testing --- cmake_minimum_required(VERSION 2.8) find_package(KDE4) - Configuring such a project returns the correct versions. Thanks, Aleix Pol Gonzalez
Re: Review Request 107716: Fix generating kconfig skeletons with UrlList fields that have a default value
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107716/#review29012 --- Ship it! Ship It! - Albert Astals Cid On March 11, 2013, 3:16 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107716/ --- (Updated March 11, 2013, 3:16 a.m.) Review request for kdelibs. Description --- This patch changes the generated code so that if a property is UrlList in the kcfg file, the variable that will receive it when generating the skeleton is a KUrl::List instead a QStringList. This solves the following compiling error: aleix@kubuntu:~/projects/muon/build$ make [ 0%] Built target muonprivate_automoc [ 0%] Building CXX object libmuon/CMakeFiles/muonprivate.dir/MuonDataSources.o In file included from /usr/include/kcoreconfigskeleton.h:28:0, from /usr/include/kconfigskeleton.h:28, from /home/aleix/projects/muon/build/libmuon/MuonDataSources.h:8, from /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:4: /usr/include/kurl.h: In constructor ‘MuonDataSources::MuonDataSources()’: /usr/include/kurl.h:1146:3: error: ‘KUrl::operator QString() const’ is private /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:38:105: error: within this context Diffs - kdecore/kconfig_compiler/kconfig_compiler.cpp 493c7d1 kdeui/tests/kconfig_compiler/CMakeLists.txt 28e916f kdeui/tests/kconfig_compiler/test12.cpp.ref PRE-CREATION kdeui/tests/kconfig_compiler/test12.h.ref PRE-CREATION kdeui/tests/kconfig_compiler/test12.kcfg PRE-CREATION kdeui/tests/kconfig_compiler/test12.kcfgc PRE-CREATION kdeui/tests/kconfig_compiler/test12main.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/107716/diff/ Testing --- Thanks, Aleix Pol Gonzalez
Re: Review Request 107716: Fix generating kconfig skeletons with UrlList fields that have a default value
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107716/#review29014 --- This review has been submitted with commit e02018941445df731873edb119b3290998375bdf by Aleix Pol to branch KDE/4.10. - Commit Hook On March 11, 2013, 3:16 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107716/ --- (Updated March 11, 2013, 3:16 a.m.) Review request for kdelibs. Description --- This patch changes the generated code so that if a property is UrlList in the kcfg file, the variable that will receive it when generating the skeleton is a KUrl::List instead a QStringList. This solves the following compiling error: aleix@kubuntu:~/projects/muon/build$ make [ 0%] Built target muonprivate_automoc [ 0%] Building CXX object libmuon/CMakeFiles/muonprivate.dir/MuonDataSources.o In file included from /usr/include/kcoreconfigskeleton.h:28:0, from /usr/include/kconfigskeleton.h:28, from /home/aleix/projects/muon/build/libmuon/MuonDataSources.h:8, from /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:4: /usr/include/kurl.h: In constructor ‘MuonDataSources::MuonDataSources()’: /usr/include/kurl.h:1146:3: error: ‘KUrl::operator QString() const’ is private /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:38:105: error: within this context Diffs - kdecore/kconfig_compiler/kconfig_compiler.cpp 493c7d1 kdeui/tests/kconfig_compiler/CMakeLists.txt 28e916f kdeui/tests/kconfig_compiler/test12.cpp.ref PRE-CREATION kdeui/tests/kconfig_compiler/test12.h.ref PRE-CREATION kdeui/tests/kconfig_compiler/test12.kcfg PRE-CREATION kdeui/tests/kconfig_compiler/test12.kcfgc PRE-CREATION kdeui/tests/kconfig_compiler/test12main.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/107716/diff/ Testing --- Thanks, Aleix Pol Gonzalez
Re: Review Request 107716: Fix generating kconfig skeletons with UrlList fields that have a default value
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107716/ --- (Updated March 11, 2013, 6:42 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Description --- This patch changes the generated code so that if a property is UrlList in the kcfg file, the variable that will receive it when generating the skeleton is a KUrl::List instead a QStringList. This solves the following compiling error: aleix@kubuntu:~/projects/muon/build$ make [ 0%] Built target muonprivate_automoc [ 0%] Building CXX object libmuon/CMakeFiles/muonprivate.dir/MuonDataSources.o In file included from /usr/include/kcoreconfigskeleton.h:28:0, from /usr/include/kconfigskeleton.h:28, from /home/aleix/projects/muon/build/libmuon/MuonDataSources.h:8, from /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:4: /usr/include/kurl.h: In constructor ‘MuonDataSources::MuonDataSources()’: /usr/include/kurl.h:1146:3: error: ‘KUrl::operator QString() const’ is private /home/aleix/projects/muon/build/libmuon/MuonDataSources.cpp:38:105: error: within this context Diffs - kdecore/kconfig_compiler/kconfig_compiler.cpp 493c7d1 kdeui/tests/kconfig_compiler/CMakeLists.txt 28e916f kdeui/tests/kconfig_compiler/test12.cpp.ref PRE-CREATION kdeui/tests/kconfig_compiler/test12.h.ref PRE-CREATION kdeui/tests/kconfig_compiler/test12.kcfg PRE-CREATION kdeui/tests/kconfig_compiler/test12.kcfgc PRE-CREATION kdeui/tests/kconfig_compiler/test12main.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/107716/diff/ Testing --- Thanks, Aleix Pol Gonzalez
Re: kwalletmanager ui refactor
On Sunday 03 February 2013 17:50:05 Andrei Sebastian Cîmpean wrote: On Sunday 03 February 2013 16:40:04 Anders Lund wrote: Søndag den 3. februar 2013 14:50:33 skrev Valentin Rusu: Great to get rid of that extra window! What I think is why even the graphical representation of it? How many people have more than one wallet? And would they loose functionality if the option to switch was represented by a menu (Files-Wallet-)? Anders Or just show the pane if there are more than one wallets. This is now done, e.g. the wallet list only shows when user has more than one wallet. The code is not yet merged to master, but you can check the ui-refactor branch if you're feeling adventurous :) -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
Re: kwalletmanager ui refactor
On Tuesday 12 February 2013 14:10:23 Aurélien Gâteau wrote: Le Wednesday 06 February 2013 23:14:59 Valentin Rusu a écrit : Thanks, I understand it better now. Assuming it was also possible to get a list of the authorized applications, I created a new revision of the mockups which show the list of currently connected applications as well as the list of authorized applications: http://agateau.com/tmp/kwalletmanager/3/ I think it is good to create a separate tab for those because this way the application can provide an explanation of the list(s). Being not intimate with the way KWalletManager works, I didn't understand what the Disconnect button would do. This may happen to others as well :) Nice proposal. I'll stick with your sketch as it'll provide also for the future, when we'll switch to ksecretsservice. Thanks. Great! Well, you can now see the results in kdeutils/kwallet:ui-refactor branch. Any feedback? Oh, in order to get the menus correctly built, you may want to do the make install from the ui-refactor branch. However, don't be afraid as the code is pretty stable - I'm already using it on my system. :) -- Valentin Rusu (vrusu) IRC: valir KSecretsService (aka KSecretService, KWallet replacement)
