Jenkins build is back to stable : kservice_master_qt5 #191
See http://build.kde.org/job/kservice_master_qt5/191/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- Review request for KDE Frameworks. Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Oct. 15, 2014, 10:42 a.m.) Review request for KDE Frameworks and David Faure. Changes --- added david. it looks OK to me, but he knows more foo. esp. considering the comment above which says docPath could be a full URL might not work now anymore... Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/ --- (Updated Oct. 15, 2014, 10:50 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin. Repository: kdeclarative Description --- Moves the caching types used in Plasma Workspace into a QuickAddons submodule. Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter item. Uses the same strategies used in Plasma Framework for caching the textures. Diffs - src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 src/quickaddons/CMakeLists.txt PRE-CREATION src/quickaddons/imagetexturescache.h PRE-CREATION src/quickaddons/imagetexturescache.cpp PRE-CREATION src/quickaddons/managedtexturenode.h PRE-CREATION src/quickaddons/managedtexturenode.cpp PRE-CREATION tests/qiconitem_test.qml PRE-CREATION src/CMakeLists.txt eb0dfd3 Diff: https://git.reviewboard.kde.org/r/120550/diff/ Testing --- I added some manual test (that was impossible to run before the patch). Also tested it in KRunner and Muon Discover, which use the component. Everything still works. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120596: Adopt QuickAddons in plasma-framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120596/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Removes the code that was moved to QuickAddons Diffs - src/declarativeimports/core/framesvgitem.cpp bb4dc69 src/declarativeimports/core/iconitem.cpp 4f3d5d6 src/declarativeimports/core/svgitem.cpp 50807d4 src/declarativeimports/core/svgtexturenode.h 8cc7bb3 src/plasmaquick/CMakeLists.txt a10beab src/declarativeimports/core/CMakeLists.txt 9aba919 src/declarativeimports/core/framesvgitem.h 73494d4 Diff: https://git.reviewboard.kde.org/r/120596/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Okt. 15, 2014, 1:08 nachm.) Review request for KDE Frameworks and David Faure. Changes --- Added a comment Repository: kconfigwidgets Description (updated) --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Okt. 15, 2014, 1:09 nachm.) Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description (updated) --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct path might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120596: Adopt QuickAddons in plasma-framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120596/ --- (Updated Oct. 15, 2014, 11:24 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Removes the code that was moved to QuickAddons Diffs - src/declarativeimports/core/framesvgitem.cpp bb4dc69 src/declarativeimports/core/iconitem.cpp 4f3d5d6 src/declarativeimports/core/svgitem.cpp 50807d4 src/declarativeimports/core/svgtexturenode.h 8cc7bb3 src/plasmaquick/CMakeLists.txt a10beab src/declarativeimports/core/CMakeLists.txt 9aba919 src/declarativeimports/core/framesvgitem.h 73494d4 Diff: https://git.reviewboard.kde.org/r/120596/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120598: Offer also overwrite option when copying multiple files and there is a conflict
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120598/ --- Review request for KDE Frameworks. Repository: kio Description --- When copying multiple files there are only options to rename and skip already existing files, but in KDE 4 I was used to also overwrite them. This patch just simply adds this option to RenameDialog in Kio::CopyJob. Diffs - src/core/copyjob.cpp 9f1826a Diff: https://git.reviewboard.kde.org/r/120598/diff/ Testing --- I tested it in Dolphin and it seems to work. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120599: Properly construct QUrl for a temporary file which will be copied as a new file or edited
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120599/ --- Review request for KDE Frameworks. Repository: kio Description --- In KNewFileMenu when trying to copy a temporary file as a new file or editing a desktop file it doesn't contruct the URL properly and it fails to create it and returns a KIO error. Diffs - src/filewidgets/knewfilemenu.cpp a24ac9c Diff: https://git.reviewboard.kde.org/r/120599/diff/ Testing --- Tested in dolphin and now I'm able to create a new text file or link to an application. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120599: Properly construct QUrl for a temporary file which will be copied as a new file or edited
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120599/ --- (Updated Říj. 15, 2014, 1:05 odp.) Review request for KDE Frameworks and David Faure. Changes --- Added David Faure to this review. Repository: kio Description --- In KNewFileMenu when trying to copy a temporary file as a new file or editing a desktop file it doesn't contruct the URL properly and it fails to create it and returns a KIO error. Diffs - src/filewidgets/knewfilemenu.cpp a24ac9c Diff: https://git.reviewboard.kde.org/r/120599/diff/ Testing --- Tested in dolphin and now I'm able to create a new text file or link to an application. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120598: Offer also overwrite option when copying multiple files and there is a conflict
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120598/ --- (Updated Říj. 15, 2014, 1:05 odp.) Review request for KDE Frameworks and David Faure. Changes --- Added David Faure to this review. Repository: kio Description --- When copying multiple files there are only options to rename and skip already existing files, but in KDE 4 I was used to also overwrite them. This patch just simply adds this option to RenameDialog in Kio::CopyJob. Diffs - src/core/copyjob.cpp 9f1826a Diff: https://git.reviewboard.kde.org/r/120598/diff/ Testing --- I tested it in Dolphin and it seems to work. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120599: Properly construct QUrl for a temporary file which will be copied as a new file or edited
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120599/#review68451 --- Ship it! Ship It! - Lukáš Tinkl On Říj. 15, 2014, 3:02 odp., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120599/ --- (Updated Říj. 15, 2014, 3:02 odp.) Review request for KDE Frameworks. Repository: kio Description --- In KNewFileMenu when trying to copy a temporary file as a new file or editing a desktop file it doesn't contruct the URL properly and it fails to create it and returns a KIO error. Diffs - src/filewidgets/knewfilemenu.cpp a24ac9c Diff: https://git.reviewboard.kde.org/r/120599/diff/ Testing --- Tested in dolphin and now I'm able to create a new text file or link to an application. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kde-baseapps_frameworks_qt5 #142
See http://build.kde.org/job/kde-baseapps_frameworks_qt5/142/ -- [...truncated 6949 lines...] KUrl::List currentURLs() const; ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:217:43: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void setLocationBarURL( const KUrl url ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:298:53: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void setTabIcon( const KUrl url, QWidget* sender ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:353:248: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void slotPopupMenu( const QPoint global, const KUrl url, mode_t mode, const KParts::OpenUrlArguments args, const KParts::BrowserArguments browserArgs, KParts::BrowserExtension::PopupFlags f, const KParts::BrowserExtension::ActionGroupMap ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:358:129: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void slotOpenURLRequest( const KUrl url, const KParts::OpenUrlArguments args, const KParts::BrowserArguments browserArgs ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:360:150: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void openUrlRequestHelper( KonqView *childView, const KUrl url, const KParts::OpenUrlArguments args, const KParts::BrowserArguments browserArgs ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:364:61: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] KParts::ReadOnlyPart **part = 0 ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:508:33: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void slotOpenURL( const KUrl ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:517:62: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void slotAddWebSideBar(const KUrl url, const QString name); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:532:47: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] KonqView * senderView ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:564:40: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] QString detectNameFilter( KUrl url ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:588:38: warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations] void setUpEnabled( const KUrl url ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/../../../konqueror/src/konqmainwindow.h:721:10: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] KUrl m_popupUrl; ^ In file included from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/kdeinit_konqueror_automoc.cpp:21:0: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/moc_konqmainwindow.cpp: In static member function ‘static void KonqMainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’:
Build failed in Jenkins: kde-baseapps_frameworks_qt5 #143
See http://build.kde.org/job/kde-baseapps_frameworks_qt5/143/changes Changes: [emmanuelpescosta099] Replaced the ItemState structure with QPairKFileItem, KVersionControlPlugin2::ItemVersion -- [...truncated 6997 lines...] KUrl m_popupUrl; ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqmain.cpp: In function ‘void listProfiles()’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqmain.cpp:46:37: warning: ‘KStandardDirs* KGlobal::dirs()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kglobal.h:375) [-Wdeprecated-declarations] QStringList profiles = KGlobal::dirs()-findAllResources(data, konqueror/profiles/*, KStandardDirs::NoDuplicates); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqmain.cpp:46:42: warning: ‘KStandardDirs* KGlobal::dirs()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kglobal.h:375) [-Wdeprecated-declarations] QStringList profiles = KGlobal::dirs()-findAllResources(data, konqueror/profiles/*, KStandardDirs::NoDuplicates); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqmain.cpp: In function ‘int kdemain(int, char**)’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqmain.cpp:94:21: warning: ‘KCmdLineOptions’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kcmdlineargs.h:53) [-Wdeprecated-declarations] KCmdLineOptions options; ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqmain.cpp:121:19: warning: ‘KCmdLineArgs’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kcmdlineargs.h:286) [-Wdeprecated-declarations] KCmdLineArgs *args = KCmdLineArgs::parsedArgs(); ^ In file included from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/kdeinit_konqueror_automoc.cpp:21:0: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/moc_konqmainwindow.cpp: In static member function ‘static void KonqMainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/moc_konqmainwindow.cpp:596:103: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] case 3: _t-openUrl((*reinterpret_cast KonqView*(*)(_a[1])),(*reinterpret_cast const KUrl(*)(_a[2])),(*reinterpret_cast const QString(*)(_a[3])),(*reinterpret_cast const KonqOpenURLRequest(*)(_a[4])),(*reinterpret_cast bool(*)(_a[5]))); break; ^ In file included from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/kdeinit_konqueror_automoc.cpp:21:0: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/moc_konqmainwindow.cpp:597:103: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] case 4: _t-openUrl((*reinterpret_cast KonqView*(*)(_a[1])),(*reinterpret_cast const KUrl(*)(_a[2])),(*reinterpret_cast const QString(*)(_a[3])),(*reinterpret_cast const KonqOpenURLRequest(*)(_a[4]))); break; ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/moc_konqmainwindow.cpp:598:103: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] case 5: _t-openUrl((*reinterpret_cast KonqView*(*)(_a[1])),(*reinterpret_cast const KUrl(*)(_a[2])),(*reinterpret_cast const QString(*)(_a[3]))); break; ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/build/konqueror/src/moc_konqmainwindow.cpp:599:103: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] case 6: _t-openUrl((*reinterpret_cast KonqView*(*)(_a[1])),(*reinterpret_cast const KUrl(*)(_a[2]))); break;
Build failed in Jenkins: kde-baseapps_frameworks_qt5 #144
See http://build.kde.org/job/kde-baseapps_frameworks_qt5/144/changes Changes: [montel] Port to QDialog -- [...truncated 2949 lines...] void KFindTreeView::removeItem(const KUrl url) ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp: In member function ‘void KFindTreeView::removeItem(const KUrl)’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:415:16: warning: ‘List’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:143) [-Wdeprecated-declarations] KUrl::List list = selectedUrls(); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp: In member function ‘void KFindTreeView::saveResults()’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:442:18: warning: ‘KFileDialog’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kfiledialog.h:74) [-Wdeprecated-declarations] KFileDialog *dlg = new KFileDialog(QString(), QString(), this); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:442:28: warning: ‘KFileDialog’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kfiledialog.h:74) [-Wdeprecated-declarations] KFileDialog *dlg = new KFileDialog(QString(), QString(), this); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:450:10: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] KUrl u = dlg-selectedUrl(); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp: In member function ‘void KFindTreeView::openContainingFolder()’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:509:16: warning: ‘List’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:143) [-Wdeprecated-declarations] KUrl::List uris = selectedUrls(); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:510:10: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] QMapKUrl, int folderMaps; ^ In file included from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtGui/qwindowdefs.h:45:0, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qwidget.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qframe.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qabstractscrollarea.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qabstractitemview.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qtreeview.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/QTreeView:1, from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.h:23, from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:20: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:513:29: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] Q_FOREACH( const KUrl url, uris ) ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/kfind/kfindtreeview.cpp:515:14: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] KUrl dir = url; ^ In file included from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtGui/qwindowdefs.h:45:0, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qwidget.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qframe.h:45, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtWidgets/qabstractscrollarea.h:45, from
Build failed in Jenkins: kde-baseapps_frameworks_qt5 #145
See http://build.kde.org/job/kde-baseapps_frameworks_qt5/145/changes Changes: [montel] Port to QDialog -- [...truncated 2952 lines...] http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistoryview.cpp:253:40: warning: ‘void KUrl::populateMimeData(QMimeData*, const MetaDataMap, KUrl::MimeDataFlags) const’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:1094) [-Wdeprecated-declarations] safeURL.populateMimeData( mimeData ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistoryview.cpp:257:40: warning: ‘void KUrl::populateMimeData(QMimeData*, const MetaDataMap, KUrl::MimeDataFlags) const’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:1094) [-Wdeprecated-declarations] safeURL.populateMimeData( mimeData ); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistorysettings.cpp: In member function ‘void KonqHistorySettings::readSettings(bool)’: http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistorysettings.cpp:64:18: warning: ‘const KComponentData KGlobal::mainComponent()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kglobal.h:362) [-Wdeprecated-declarations] if (KGlobal::mainComponent().componentName() == QLatin1String(konqueror)) ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistorysettings.cpp:64:32: warning: ‘const KComponentData KGlobal::mainComponent()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kglobal.h:362) [-Wdeprecated-declarations] if (KGlobal::mainComponent().componentName() == QLatin1String(konqueror)) ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistorysettings.cpp:65:25: warning: ‘QExplicitlySharedDataPointerKSharedConfig KGlobal::config()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kglobal.h:382) [-Wdeprecated-declarations] config = KGlobal::config(); ^ http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/konqueror/src/konqhistorysettings.cpp:65:32: warning: ‘QExplicitlySharedDataPointerKSharedConfig KGlobal::config()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kglobal.h:382) [-Wdeprecated-declarations] config = KGlobal::config(); ^ In file included from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qobject.h:56:0, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qiodevice.h:47, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qdatastream.h:46, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qstringlist.h:46, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qurlquery.h:50, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qurl.h:408, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/QUrl:1, from /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kbookmarks/inst/include/KF5/KBookmarks/kbookmark.h:24, from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/keditbookmarks/favicons.h:23, from http://build.kde.org/job/kde-baseapps_frameworks_qt5/ws/keditbookmarks/favicons.cpp:20: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h: In static member function ‘static int QMetaTypeIdKUrl::qt_metatype_id()’: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qmetatype.h:1695:54: warning: ‘KUrl’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109) [-Wdeprecated-declarations] reinterpret_cast TYPE *(quintptr(-1))); \ ^ /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h: In static member function ‘static int QMetaTypeIdKUrl::List::qt_metatype_id()’: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qmetatype.h:1695:54: warning: ‘List’ is
Re: blogging about technical details (was: Re: Review Request 120099: RFC: UI-Files inside resources instead of filesystem)
On Sunday 12 October 2014 22:57:33 David Faure wrote: On Saturday 11 October 2014 16:40:55 Dominik Haumann wrote: Hi all, imho, these are changes that get mostly unnoticed, and hence close to no one will use this feature. I personally would find it very cool if there were lots and lots of blogs on the planet for these technical details. It would also communicate a bit more of the internals to potentially new developers. So feel free to interpret this mail as a call for more blogging ;) Well, I'll mention it in the KF 5.4 changelog, too. So all of kde-core-devel and kde-devel will notice. The changelog is about the what, but not about the how. The how is what's important [to me] here. For instance, it's nice to hear that KArchive supports a new format. But if there was a quick blog about how to approach this to add a new format, maybe with some cool/interesting details, then there might be someone attracted trying to add some other format. (Yes, I know I can look into the commit, but this is about e.g. some 18-22 years old potential developers that maybe don't even know what git or a commit it. I once did not knew myself...) Oh well, maybe it's just me ;) Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: private export
On Tuesday 14 October 2014 14:37:30 Jeremy Whiting wrote: Hello, In KNewStuff autotests there are two disabled tests that build and work if I export the Author and EntryInternal classes, but these two classes are private (declared in _p.h files) so I'd rather not export them, since they aren't public api. Is there a way to have them exported when BUILD_TESTING is set only? I didn't see anything obvious in the knewstuff_export.h generated header. I guess I could have the class declarations wrapped in #ifdef BUILD_TESTING but that seems like a hack. Is there a proper way to only export private classes when building and running tests? In KTextEditor we use a KTEXTEDITOR_PRIVATE_EXPORT macro that is the same as KTEXTEDITOR_EXPORT, but do not install the headers. Yes there are more symbols in the .so, but without headers it's not of much help. Greetings Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Proxy Settings KCM
El Dimecres, 15 d'octubre de 2014, a les 12:03:17, Eike Hein va escriure: Hi, I just noticed that we currently don't seem to have proxy settings in Plasma 5, meaning that clicking Proxy Settings in Rekonq or Google Chrome doesn't do anything because they try to kcmshell something that doesn't exist. Turns out the KCM resides in Konqueror, much like Web Short- cuts used to do before we moved it to KIO. Do we want to do this with the Proxy KCM too, or ...? If it sets the proxy of KIO globally, yes, i'd say it makes sense. Cheers, Albert Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/#review68515 --- You're right that fromUserInput is wrong for relative paths (that should stay relative). fromUserInput turns them to http. However as the comment says, docPath could be either relative or absolute (at least both worked in KDE4). Your patch would break absolute urls. My suggestion: url = QUrl(QLatin1String(help:/)).resolved(QUrl(docPath)); (as documented in the KUrl(a,b) constructor, which this code was using in kde4) (I might have written that docu later than when porting this code...) - David Faure On Oct. 15, 2014, 11:09 a.m., Simon Wächter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Oct. 15, 2014, 11:09 a.m.) Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct path might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120599: Properly construct QUrl for a temporary file which will be copied as a new file or edited
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120599/#review68517 --- Ship it! Correct, thanks. But please also remove the redundant if() then. src/filewidgets/knewfilemenu.cpp https://git.reviewboard.kde.org/r/120599/#comment47717 You're right. I reviewed the code, and src is always a local path. For this reason, this if() should be removed. It makes no sense to test isLocalFile() just after fromLocalFile() :-) - David Faure On Oct. 15, 2014, 1:05 p.m., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120599/ --- (Updated Oct. 15, 2014, 1:05 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- In KNewFileMenu when trying to copy a temporary file as a new file or editing a desktop file it doesn't contruct the URL properly and it fails to create it and returns a KIO error. Diffs - src/filewidgets/knewfilemenu.cpp a24ac9c Diff: https://git.reviewboard.kde.org/r/120599/diff/ Testing --- Tested in dolphin and now I'm able to create a new text file or link to an application. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120598: Offer also overwrite option when copying multiple files and there is a conflict
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120598/#review68518 --- Well spotted, porting bug: (commit 3fde4d63887ecbb57ac92f61cc36ff5240ce86f3) -mode = (RenameDialog_Mode)(mode | M_MULTI | M_SKIP); +options = RenameDialog_Options(RenameDialog_MultipleItems | RenameDialog_Skip); the mode | was lost. So let's fix this properly: it should be options | rather than hardcoding Overwrite, which is already determined in the code above. Can you check that options = RenameDialog_Options(options | RenameDialog_MultipleItems | RenameDialog_Skip); fixes your bug? Thanks. - David Faure On Oct. 15, 2014, 1:05 p.m., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120598/ --- (Updated Oct. 15, 2014, 1:05 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- When copying multiple files there are only options to rename and skip already existing files, but in KDE 4 I was used to also overwrite them. This patch just simply adds this option to RenameDialog in Kio::CopyJob. Diffs - src/core/copyjob.cpp 9f1826a Diff: https://git.reviewboard.kde.org/r/120598/diff/ Testing --- I tested it in Dolphin and it seems to work. Thanks, Jan Grulich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
On Oct. 15, 2014, 10:47 p.m., David Faure wrote: You're right that fromUserInput is wrong for relative paths (that should stay relative). fromUserInput turns them to http. However as the comment says, docPath could be either relative or absolute (at least both worked in KDE4). Your patch would break absolute urls. My suggestion: url = QUrl(QLatin1String(help:/)).resolved(QUrl(docPath)); (as documented in the KUrl(a,b) constructor, which this code was using in kde4) (I might have written that docu later than when porting this code...) Ok thank you. When I read the KDE 4 code I didn't thought about absolute paths (Missinterpreted the documentation), so I supposed the comment in the KF5 branch was more like I am not quite sure. The patch now contains your suggested change. - Simon --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/#review68515 --- On Oct. 15, 2014, 1:09 p.m., Simon Wächter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Oct. 15, 2014, 1:09 p.m.) Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct path might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Oct. 15, 2014, 11:08 p.m.) Review request for KDE Frameworks and David Faure. Changes --- Fixed the patch Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct path might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs (updated) - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/#review68522 --- Ship it! You're right that the comment, which I wrote, meant not quite sure. Now I looked at the kde4 code more precisely, and since it was using KUrl(a,b), absolute urls (urls, not just paths, like http://www.kde.org) worked. No reason to break that. Absolute paths (/tmp/foo.html) won't work, but that's fine, I don't expect them to. If anyone wanted to point to a local file they would have to use a file:/// url. The default is help:/ after all, so anything else must be explicit here. - David Faure On Oct. 15, 2014, 9:08 p.m., Simon Wächter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Oct. 15, 2014, 9:08 p.m.) Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct path might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120603: Use officially exported CMAKE paths
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120603/#review68523 --- Ship it! tnx. maybe KF5AuthMacros.cmake could also be adjusted? currently it evaluates by hand whether KAUTH_HELPER_INSTALL_DIR is relative or absolute - Hrvoje Senjan On Oct. 15, 2014, 10:45 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120603/ --- (Updated Oct. 15, 2014, 10:45 p.m.) Review request for KDE Frameworks. Repository: kauth Description --- Use officially exported CMAKE paths PLUGIN_INSTALL_DIR is not documented in the header of KDEInstallDirs More importantly on builds that use KDE_INSTALL_USE_QT_SYS_PATHS this is relative, whereas normally it's absolute. By using the CMAKE_INSTALL_FULL path we avoid that problem as it goes through the define_relatve define_absolute macros. Diffs - src/BackendsConfig.h.cmake 9b82fb8 Diff: https://git.reviewboard.kde.org/r/120603/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120595: Build correct QUrl path when KHelpClient::invokeHelp is called
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120595/ --- (Updated Okt. 15, 2014, 11:38 nachm.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- During the port of KAppTemplate to KF5 I encountered a problem with the help invokation by hand - KAppTemplate has a help button in the main window/widget. These methods were used: KDE4: KToolInvocation::invokeHelp(kapptemplate-init, kapptemplate); KF5: KHelpClient::invokeHelp(kapptemplate-init, kapptemplate); + Application name is set In KDE 4 it worked without a problem, but as soon it was ported to KF5 it stopped working. So I debugged the method and saw, that the URL for calling the help page has this (wrong) format: http://kapptemplate/index.html?anchor=kapptemplate-index So, because the help address is an http-Url, I wrote a fix and the final URL now looks like this: help:/kapptemplate/index.html?anchor=kapptemplate-index This URL is KHelpCenter-valid and will call KHelpCenter. You can also take a look at the else part of that line: If no application is given, _appname is used and inserted in the correct url. As addition: As mentioned, the correct path might (is ?) not correct. But the problem is still, that if docPath has some content (In this case: kapptemplate/index.html), the url is interpreted as http one. Diffs - src/khelpclient.cpp 09a3167 Diff: https://git.reviewboard.kde.org/r/120595/diff/ Testing --- Testing was done under a project neon 5 system and with the current master branch of KConfigWidgets from git. Before installing the patched library, the help menu was not invokable from the KAppTemplate application. After installing the patching library it was. Also tested it with Kate help menu item from the Settings menu. It is also callable from Settings -- Configure Kate -- Help (Bottom left). Thanks, Simon Wächter ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120603: Use officially exported CMAKE paths
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120603/#review68528 --- Ship it! Ship It! - Aleix Pol Gonzalez On Oct. 15, 2014, 8:45 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120603/ --- (Updated Oct. 15, 2014, 8:45 p.m.) Review request for KDE Frameworks. Repository: kauth Description --- Use officially exported CMAKE paths PLUGIN_INSTALL_DIR is not documented in the header of KDEInstallDirs More importantly on builds that use KDE_INSTALL_USE_QT_SYS_PATHS this is relative, whereas normally it's absolute. By using the CMAKE_INSTALL_FULL path we avoid that problem as it goes through the define_relatve define_absolute macros. Diffs - src/BackendsConfig.h.cmake 9b82fb8 Diff: https://git.reviewboard.kde.org/r/120603/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120603: Use officially exported CMAKE paths
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120603/ --- (Updated Oct. 15, 2014, 11:30 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kauth Description --- Use officially exported CMAKE paths PLUGIN_INSTALL_DIR is not documented in the header of KDEInstallDirs More importantly on builds that use KDE_INSTALL_USE_QT_SYS_PATHS this is relative, whereas normally it's absolute. By using the CMAKE_INSTALL_FULL path we avoid that problem as it goes through the define_relatve define_absolute macros. Diffs - src/BackendsConfig.h.cmake 9b82fb8 Diff: https://git.reviewboard.kde.org/r/120603/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
