Re: Moving KPlugionLoader|Factory to KCoreAddons?
On Saturday 29 March 2014 00:38:36 Alex Merry wrote: While doing work on KService, I realised that KPluginLoader, KPluginFactory and KExportPlugin could all quite happily go in KCoreAddons, and it would be really nice to have them there (KPluginTrader would stay in KService, of course). I'm not sure of the BCness or SCness of this, though. I think it might be BC, since KService links to KCoreAddons. We'd have to include KCoreAddons in KService's link interface, since kservice.h uses KPluginLoader and KPluginFactory in a template method, so I think it would also be SC. If that's the case (the SCness in particular), does that move seem reasonable? Yes, this sounds SC indeed, and it makes sense in order to reduce dependencies. Go ahead. One thing will not be SC though: you'll have to remove this include: kpluginfactory.h:30:#include ksharedconfig.h // for source compat -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: plasma-framework_master_qt5 » All,LINBUILDER #212
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/212/changes Changes: [faure] Upgrade ECM version requirement and KF5 version. -- Started by upstream project plasma-framework_master_qt5 build number 212 originally caused by: Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/ Running Prebuild steps [LINBUILDER] $ /bin/sh -xe /tmp/hudson8275619154957989600.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/plasma-framework 8d786e2..ae9cd4d master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 8d786e2 SVN_SILENT made messages (.desktop file) Removing build/ Removing dotdata/ Removing install/ Success build forhudson.tasks.Shell@7fae3d8d Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/plasma-framework.git Checking out Revision ae9cd4d7a9e8063d3fc07b827fa8eea86bfc2868 (refs/heads/jenkins) [LINBUILDER] $ /bin/sh -xe /tmp/hudson3040915140515835593.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: kauth - Branch master kjs - Branch master ki18n - Branch master kitemviews - Branch master kwidgetsaddons - Branch master qt5 - Branch stable kconfigwidgets - Branch master knotifications - Branch master ktextwidgets - Branch master threadweaver - Branch master kiconthemes - Branch master kcoreaddons - Branch master kwallet - Branch master kcrash - Branch master polkit-qt-1 - Branch qt5 kservice - Branch master kwindowsystem - Branch master kjobwidgets - Branch master kio - Branch master kdbusaddons - Branch master kcodecs - Branch master attica - Branch master sonnet - Branch master phonon - Branch master kitemmodels - Branch master cmake - Branch master karchive - Branch master kidletime - Branch master kdeclarative - Branch master kglobalaccel - Branch master kross - Branch master ktexteditor - Branch master kxmlgui - Branch master kbookmarks - Branch master extra-cmake-modules - Branch master kdoctools - Branch master kactivities - Branch master kdnssd - Branch master solid - Branch master kparts - Branch master kconfig - Branch master kcompletion - Branch master kunitconversion - Branch master kguiaddons - Branch master kdesupport-svn - Branch master == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.8.2 -- The CXX compiler identification is GNU 4.8.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:44 (find_package): Could not find a configuration file for package KF5Activities that is compatible with requested version 4.98.0. The following configuration files were considered but not accepted: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/kde/kdelibs/kactivities/inst/lib64/cmake/KF5Activities/KF5ActivitiesConfig.cmake, version: 4.97.0 -- Configuring incomplete, errors occurred! See also http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/build/CMakeFiles/CMakeOutput.log;. Configure step exited with non-zero code, assuming failure to configure for project plasma-framework. Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE Skipping Cobertura coverage report as build was not UNSTABLE or better ... Recording test results ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: plasma-framework_master_qt5 » NoX11,LINBUILDER #212
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/212/changes Changes: [faure] Upgrade ECM version requirement and KF5 version. -- Started by upstream project plasma-framework_master_qt5 build number 212 originally caused by: Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 3 (PACKAGER LINBUILDER) in workspace http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/ Running Prebuild steps [LINBUILDER] $ /bin/sh -xe /tmp/hudson2939780987986573042.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/plasma-framework 91cb51e..ae9cd4d master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 91cb51e fix behavior of inverted sliders Success build forhudson.tasks.Shell@7fae3d8d Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/plasma-framework.git Checking out Revision ae9cd4d7a9e8063d3fc07b827fa8eea86bfc2868 (refs/heads/jenkins) [LINBUILDER] $ /bin/sh -xe /tmp/hudson2030383585706167444.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: attica - Branch master kauth - Branch master phonon - Branch master kjs - Branch master ki18n - Branch master kwidgetsaddons - Branch master qt5 - Branch stable kidletime - Branch master knotifications - Branch master threadweaver - Branch master kdesupport-svn - Branch master kiconthemes - Branch master kxmlgui - Branch master kcoreaddons - Branch master kwallet - Branch master kcrash - Branch master polkit-qt-1 - Branch qt5 kjobwidgets - Branch master kio - Branch master kdbusaddons - Branch master kcodecs - Branch master sonnet - Branch master kitemmodels - Branch master kitemviews - Branch master kdnssd - Branch master kwindowsystem - Branch master karchive - Branch master kdeclarative - Branch master kglobalaccel - Branch master kross - Branch master ktexteditor - Branch master kparts - Branch master kservice - Branch master kbookmarks - Branch master ktextwidgets - Branch master kdoctools - Branch master kactivities - Branch master kconfigwidgets - Branch master solid - Branch master extra-cmake-modules - Branch master cmake - Branch master kconfig - Branch master kcompletion - Branch master kunitconversion - Branch master kguiaddons - Branch master == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.8.2 -- The CXX compiler identification is GNU 4.8.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:44 (find_package): Could not find a configuration file for package KF5Activities that is compatible with requested version 4.98.0. The following configuration files were considered but not accepted: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/kde/kdelibs/kactivities/inst/lib64/cmake/KF5Activities/KF5ActivitiesConfig.cmake, version: 4.97.0 -- Configuring incomplete, errors occurred! See also http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/build/CMakeFiles/CMakeOutput.log;. Configure step exited with non-zero code, assuming failure to configure for project plasma-framework. Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE Skipping Cobertura coverage report as build was not UNSTABLE or better ... Recording test results ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : plasma-framework_master_qt5 » All,LINBUILDER #213
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/213/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : plasma-framework_master_qt5 » NoX11,LINBUILDER #213
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/213/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons5 extraction
On Friday 28 March 2014 19:15:26 Luigi Toscano wrote: On Friday 28 of March 2014 19:28:16 Yuri Chornoivan wrote: Hi, https://projects.kde.org/projects/frameworks/kcoreaddons/repository/revisi on s/master/entry/src/lib/kaboutdata.cpp#L258 licenseShort = QCoreApplication::translate(KAboutLicense, @item license (short name), GPL v2); is extracted as (the same thing for the others) #: ../../home/scripty/prod/git-unstable/frameworks_kcoreaddons/src/lib/kabout da ta.cpp:258 msgctxt KAboutLicense|GPL v2 msgid @item license (short name) msgstr So what is wrong? Extraction script or the order of parameters for all licenses? Thanks in advance for your answers. Hi Yuri, this is a good question also for kde-frameworks-devel@ (now in cc) Yes the argument order was wrong, and this was fixed yesterday (it was also detected by a unittest, by chance) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117147: use renamed kf5_entry.desktop file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117147/#review54525 --- Ship it! Well it's part of the already-in https://git.reviewboard.kde.org/r/117087/, so go ahead. - David Faure On March 28, 2014, 7:20 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117147/ --- (Updated March 28, 2014, 7:20 p.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: kio Description --- entry.desktop got renamed, use the renamed file https://git.reviewboard.kde.org/r/117087/ Diffs - src/core/global.cpp 99ab2e7 Diff: https://git.reviewboard.kde.org/r/117147/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117148: use renamed kf5_entry.desktop file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117148/#review54526 --- No, no. This is a language entry.desktop file, not a country desktop file. Only the latter come from kde-runtime (and those are the ones you renamed). The former come from the translations. The i18n/l10n naming confusion doesn't help, I admit. (kde-l10n = new style = l10n means translating into a language, was called i18n before; kde-runtime/l10n = old style = l10n means adapting to a country) - David Faure On March 28, 2014, 7:22 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117148/ --- (Updated March 28, 2014, 7:22 p.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: kconfigwidgets Description --- entry.desktop got renamed, use the renamed file https://git.reviewboard.kde.org/r/117087/ Diffs - src/klanguagebutton.cpp 9f0c055 Diff: https://git.reviewboard.kde.org/r/117148/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Moving KPlugionLoader|Factory to KCoreAddons?
On Saturday 29 March 2014 07:50:20 David Faure wrote: One thing will not be SC though: you'll have to remove this include: kpluginfactory.h:30:#include ksharedconfig.h // for source compat This bit is now out of the way (I added the include in all the code that was relying on it, and removed it from here). Hopefully that makes it possible to make this move in a SC manner after beta1. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-frameworks-devel] Regarding entry.desktop files
On Friday 28 March 2014 21:27:05 Jonathan Riddell wrote: Thanks for the information. My main concern is that kf5 and kde-runtime can be installed alongside the kdelibs4 equivalents without overlapping files. I didn't know there were entry.desktop files in kde-runtime too but I see them now. I've committed a change to kde4support to rename the C entry.desktop file to kf5_entry.desktop. And also patched kde4support internally to use kf5_entry.desktop. Note that the patch in question is wrong, since it mixes both kinds of entry.desktop files. ./src/kdecore/klocale_kde.cpp:401:KConfig entryFile(QStandardPaths::locate(QStandardPaths::GenericDataLocation, QLatin1String(locale/) + QString::fromLatin1(l10n/%1/kf5_entry.desktop).arg(m_country))); Wrong, since countries (from kde-runtime) don't get named that way. (same problem in 2 other lines in kde4support) ./src/kdecore/klocale_kde.cpp:498:KConfig langCfg(QStandardPaths::locate(QStandardPaths::GenericDataLocation, QLatin1String(locale/) + QString::fromLatin1(%1/kf5_entry.desktop).arg(m_language))); Right, if you remember to adjust kde-l10n-* as well. Can you say if this is the right thing to do? It'll mean the other files in kde-l10n-* also need renamed. Yes. The contents of /usr/share/locale/l10n can probably be moved wholesale into /usr/share/locale/l10n-kf5 or similar. Would that be sensible? Yes. But while at it, I would rename entry.desktop to country.desktop or something, it's getting really confusing with all the things called l10n and entry.desktop in here. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116461/ --- (Updated March 29, 2014, 9:08 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation. KConfig already parses the config files from disk in the constructor, which is necessary for non-KConfigXT users. However when using KConfigXT the first thing one has to do after creation is to call readConfig(), which should therefore not call reparseConfiguration the first time. strace -e open kate | grep -v NOENT | grep oxygenrc | wc -l went from 4 to 1 -- bingo, goal reached! (and when looking for kdeglobals, from 10 to 7) Diffs - src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f src/core/kcoreconfigskeleton_p.h 0b020ed3493186e699d872ddc7a9f9294d797a95 Diff: https://git.reviewboard.kde.org/r/116461/diff/ Testing --- (see commit log) + unittests in kconfig still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Friday 28 March 2014 15:42:16 David Faure wrote: Well we can't deprecate both khtml and kdewebkit. What do we use then, right now, to browse the web in a KDE application? Deprecate does not mean that both are not available any longer, just that 3rd party developers don't get a wrong impression that it'll be well maintained for the entirety of the KF5 series. Unless someone steps in to maintain QtWebKit, QtWebEngine is the sole future... ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons5 extraction
2014-03-28 22:15 GMT+04:00 Luigi Toscano luigi.tosc...@tiscali.it: On Friday 28 of March 2014 19:28:16 Yuri Chornoivan wrote: Hi, https://projects.kde.org/projects/frameworks/kcoreaddons/repository/revision s/master/entry/src/lib/kaboutdata.cpp#L258 licenseShort = QCoreApplication::translate(KAboutLicense, @item license (short name), GPL v2); is extracted as (the same thing for the others) #: ../../home/scripty/prod/git-unstable/frameworks_kcoreaddons/src/lib/kaboutda ta.cpp:258 msgctxt KAboutLicense|GPL v2 msgid @item license (short name) msgstr So what is wrong? Extraction script or the order of parameters for all licenses? Hello, I didn't play with Qt i18n API much, but in this case it's clear from the Qt docs [1] that the order of parameters in the code is wrong. The source text (e.g. GPL v2) is should be passed as the second parameter, msgctxt @item license (short name) being the third one. [1] http://qt-project.org/doc/qt-5.0/qtcore/qcoreapplication.html#translate -- Alexander Potashev ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117155: EGH - Also look for headers in the build dir
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117155/ --- Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- When generating headers, ecm_generate_headers only looks on CMAKE_CURRENT_SOURCE_DIR. This patch makes it also look in CMAKE_CURRENT_BINARY_DIR before throwing an error. This way, generated headers (e.g: kcfg files) don't have to be treated manually. Diffs - modules/ECMGenerateHeaders.cmake 739c211 Diff: https://git.reviewboard.kde.org/r/117155/diff/ Testing --- Thanks, Christophe Giboudeaux ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117147: use renamed kf5_entry.desktop file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117147/#review54534 --- This review has been submitted with commit 724d4017856eacfb3c94b5eeaa880ba0f5a731d3 by Jonathan Riddell to branch master. - Commit Hook On March 28, 2014, 7:20 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117147/ --- (Updated March 28, 2014, 7:20 p.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: kio Description --- entry.desktop got renamed, use the renamed file https://git.reviewboard.kde.org/r/117087/ Diffs - src/core/global.cpp 99ab2e7 Diff: https://git.reviewboard.kde.org/r/117147/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117147: use renamed kf5_entry.desktop file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117147/ --- (Updated March 29, 2014, 10:28 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: kio Description --- entry.desktop got renamed, use the renamed file https://git.reviewboard.kde.org/r/117087/ Diffs - src/core/global.cpp 99ab2e7 Diff: https://git.reviewboard.kde.org/r/117147/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117155: EGH - Also look for headers in the build dir
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117155/ --- (Updated March 29, 2014, 10:51 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- When generating headers, ecm_generate_headers only looks on CMAKE_CURRENT_SOURCE_DIR. This patch makes it also look in CMAKE_CURRENT_BINARY_DIR before throwing an error. This way, generated headers (e.g: kcfg files) don't have to be treated manually. Diffs - modules/ECMGenerateHeaders.cmake 739c211 Diff: https://git.reviewboard.kde.org/r/117155/diff/ Testing --- Thanks, Christophe Giboudeaux ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117154: Simplify the plugin lookup code
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117154/ --- (Updated March 29, 2014, 11:01 a.m.) Review request for KDE Frameworks, kdewin, Alexander Richardson, and David Faure. Repository: kservice Description --- Simplify the plugin lookup code Diffs - src/plugin/kpluginloader.cpp 1602c180db5e1a5f0765d95d68f90d2046c9ef2b Diff: https://git.reviewboard.kde.org/r/117154/diff/ Testing --- Builds, tests pass and generally seems to work on my Linux machine. Windows stuff completely untested. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-frameworks-devel] Regarding entry.desktop files
David Faure ha scritto: On Friday 28 March 2014 21:27:05 Jonathan Riddell wrote: Can you say if this is the right thing to do? It'll mean the other files in kde-l10n-* also need renamed. Yes. I'm a bit confused now: what files are to be renamed? The ones in the SVN repository under lang/messages/entry.desktop ? If the answer is yes, then maybe we really need to create a base trunk/l10n-kf5 directory and track Frameworks (and KF5-based application) translations from there, before any other renaming. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : ktexteditor_master_qt5 #350
See http://build.kde.org/job/ktexteditor_master_qt5/350/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117146: Remove unused dependencies
On March 29, 2014, 12:02 a.m., Aleix Pol Gonzalez wrote: src/kdeui/kglobalsettings.cpp, line 61 https://git.reviewboard.kde.org/r/117146/diff/1/?file=258003#file258003line61 Why comment it? We either need it or don't need it... I did this so that it's there but not there, like the ifdefd out code that was the xcb consumer. - Michael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117146/#review54518 --- On March 28, 2014, 6:55 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117146/ --- (Updated March 28, 2014, 6:55 p.m.) Review request for KDE Frameworks. Repository: kde4support Description --- * Comment out xcb include, since its only usage is ifdefd out * Remove KF5 dependencies that are not used * The KF5::ItemViews link was only indirectly used to link against KIO, but that's fixed there now Diffs - CMakeLists.txt ef8bfede0b878b2c853a8cd17b0c36c997f5a9dc src/CMakeLists.txt f21e7ddfb20337337bef344f877ac8b8f68640fe src/kdeui/kglobalsettings.cpp 8de898639e4236659291fc2297dab312a0db7357 Diff: https://git.reviewboard.kde.org/r/117146/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Saturday, 2014-03-29, 01:21:24, Aleix Pol wrote: On Fri, Mar 28, 2014 at 9:14 PM, Kevin Krammer kram...@kde.org wrote: I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin Well, I think that what Boudewijn means is that even though we can use DBus on Windows, we might not really want to. Not only for deployment constraints but also because then you need to take care of having it running and management. It can be more of a promo statement more than actual technical advice, but I prefer happy users of few frameworks than slightly frustrated users of many frameworks... I am not saying that we have to use D-Bus in frameworks that require out-of- process components, we can of course always use a hand crafted communication mechanism based on QLocalSocket/-Server, even on platforms that have D-Bus as part of the system installation. I am just saying that frameworks using D-Bus can be used on more platforms than just Linux. All frameworks with dynamic dependencies need to have deployment documentatation. Whether that is bundling a D-Bus installer or bundling plugins and setting custom search paths or bundling a plugin installer. And, most importantly, it is the application developer's choice which frameworks they need and which just optionally use on certain platforms. I just don't see a point in telling application developers that a certain framework is not available on certain platforms when in fact it is but some application developers might chose not to use it due to deployment requiremens. Qt doesn't restrict its supported platforms to Linux just because that is the platform where it comes pre-installed. If a platform without system Qt is widely used there can even be initiatives to remedy that somewhat, like Ministro does on Android. In other words, I don't think it's enough to be able to build and run. I think that it's fundamental also to be able to deploy it and provide an seamless and integrated experience to the user. Of course, I never stated anything to the contrary. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Moving KPlugionLoader|Factory to KCoreAddons?
On 29/03/14 00:38, Alex Merry wrote: While doing work on KService, I realised that KPluginLoader, KPluginFactory and KExportPlugin could all quite happily go in KCoreAddons, and it would be really nice to have them there (KPluginTrader would stay in KService, of course). I'm not sure of the BCness or SCness of this, though. I think it might be BC, since KService links to KCoreAddons. We'd have to include KCoreAddons in KService's link interface, since kservice.h uses KPluginLoader and KPluginFactory in a template method, so I think it would also be SC. If that's the case (the SCness in particular), does that move seem reasonable? I just realised a flaw with this: KPluginLoader has a constructor that takes a KService argument. Which is annoying, because the only difference between KPluginLoader(service) and KPluginLoader(service.library()) is the error message you get if the service is not valid or does not provide a library. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117160: solid-hardware: rename for co-installability with kdelibs4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117160/ --- Review request for KDE Frameworks. Repository: solid Description --- kde-runtime4 also installs solid-hardware, so rename it to solid-hardware5 for KF5. Diffs - src/tools/solid-hardware/CMakeLists.txt 7cb604e7bdbee605ecf71e38b050fc8841df8eb9 Diff: https://git.reviewboard.kde.org/r/117160/diff/ Testing --- Built and installed alongside kde-runtime4 Thanks, Heiko Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117161: Drop QApplication usages in units.cpp
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117161/ --- Review request for KDE Frameworks, Marco Martin and Sebastian Kügler. Repository: plasma-framework Description --- Drop dependency to QtWidgets from this file. We can start assuming that it might not be that functional in some platforms. Use QGuiApplication counterparts, based mostly on QScreen, which could make it more powerful in the future. I did it because otherwise KAlgebraMobile crashes if using the Plasma Components based interface. Diffs - src/declarativeimports/core/units.cpp f0b8d39 Diff: https://git.reviewboard.kde.org/r/117161/diff/ Testing --- Builds, KAlgebra doesn't have the problem now. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Regarding entry.desktop files
[: Aleix Pol :] So do you suggest that I move the ones in kde-runtime/l10n to kde4support? I personally can't suggest anything for these, as I'm not fully aware of the current state of the KLocale/QLocale story. John, around? :) -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-frameworks-devel] Regarding entry.desktop files
[: Luigi Toscano :] I'm a bit confused now: what files are to be renamed? The ones in the SVN repository under lang/messages/entry.desktop? I think that the best solution at the moment is: don't rename anything in the repositories, and also don't install these files at all. When it is decided how the language selection will work with KF5, revisit this matter. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
(Because of my screw up on reply, there are two messages in this thread which went only to kde-i18n-doc, sorry.) [: Harald Sitter :] At least with gettext there's fallback mechanisms in place, whether that is an expected thing to have I do not know, certainly seems like a sensible thing to have though (verification needed). In some cases the fallback will do the right thing, in same cases not. But, isn't this beside the point here? Since we are pondering how the locale/ language KCM should determine which languages are available. The examples I picked were to illustrate that such determination based on Glibc locale names is problematic. [: Chusslove Illich :] Then there are language codes that are provided by KDE now, but have no Glibc locale to it (e.g. sr@ijekavian, sr@ijekavianlatin). Then sometimes there is a change of language code (in the past e.g. sr@Latn - sr@latin, no_NN - nn), where for quite some time the deprecated code should be supported. [: Harald Sitter :] To be honest, I strongly believe all of this is a home made problem. If we got codes created upstream in glibc rather than make them up ourselves, there'd be no problem to speak of. And as far as I can tell glibc code vs. gettext code is a 1:1 mapping, so then we might just be able to only talk about locales and not locales+languages. In an ideal world, yes. But in a very, very ideal world. For Glibc, for example, special cases are strongly adversely affected by the D-factor (e.g. Serbian Ijekavian locales were turned down once). But even if the Glibc situation were all-clear on its own, Glibc/Gettext is not the only locale/ translation system. [: Chusslove Illich :] [...] what about Qt locales, which have nothing to do with Glibc locales. But other than that, yes, I too think there should be direct selection of the locale -- but for each locale system (Glibc/Qt/etc). And then the KCM should set LANG for Glibc, and so on for the rest. [: Harald Sitter :] I thought Qt follows the platform rule, in this case glibc? In Qt I can see that it has internal definitions of locales. I don't know if and when Qt will use Glibc's definitions, and in what way. Considering everything we'd need two configurations (this is assuming KDE language codes continue to not be system locale codes): In the following you were specifying something more capable than just using Glibc locales, but... In my opinion, there are two approaches that can work. One is locale/translation system Y is the whole world (such as with some other DEs and Glibc/Gettext). Everything outside this system is just ignored. It is responsibility of every other locale/translation system to adapt itself to settings of locale/translation system Y, or not, and that's it. The other approach is a modular one. By examining the features of extant locale/translation systems, we define a set of abstract choices (e.g. language and country) that are to be presented to the user. These choices are not directly related to any one locale/translation system on its own. This is one module. The second module is collecting the information on the system, in any number of heuristic ways, in orther to make a reduction of all possible choices (e.g. available languages). Here come distro- /platform-specific hooks and so on. The third module is making sure that any known locale/translation systems are initialized properly according to user's selection of abstract choices. It should also allow direct override of all elements, in advanced-something section. I think this is the only way to prevent spaggetization of the code. Furthermore, I think this system should be part of Frameworks themselves. KCM would be a simple wrapper around it. The benefit is that then we can keep the current feature of selecting language per application: instead of current half-baked solution, it would open a dialog which is exactly the same as the one in the KCM, allowing the user to tune exactly everything on the application level as can be done on the session level. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: small but Big request
On Friday 28 March 2014 16:17:19 David Boosalis wrote: At the risk of getting 50 lashes. Can I make a request for new KDE Git build instructions. All the instructions for building might be out there and I know there is the uber kdesrc-build script, but you really got to squint to get all the details just right. Spring has yet to arrive in Canada, and I thought it would be nice to try and build KDE5 from Git this weekend. There might be others like me that want to try this exercise. I assume with KDE5 you mean all the frameworks and maybe Plasma 2? For the frameworks there are build instructions: http://community.kde.org/Frameworks/Building It's written around kdesrc-build and I can only recommend to use that tool and don't try to build it manually. Just having the dependency resolutions between all the frameworks is rather complex. So use the tooling :-) The nice thing about using kdesrc-build is that you easily get also Plasma 2 and the frameworks based applications. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Review Request 117090: add version to libmolletnetwork
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117090/#review54533 --- This review has been submitted with commit d9c6e9aacf46ec8c561ac8793d56e3e0ec7f518d by Jonathan Riddell to branch frameworks. - Commit Hook On March 26, 2014, 4:10 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117090/ --- (Updated March 26, 2014, 4:10 p.m.) Review request for KDE Runtime and Aleix Pol Gonzalez. Repository: kde-runtime Description --- add soversion to libmolletnetwork, currently it installs as libmolletnetwork.so.SOVERSION which can't be right. used a simple static version number as inspired by libksysguard in kde-workspace Diffs - kioslave/network/network/CMakeLists.txt ad72048 Diff: https://git.reviewboard.kde.org/r/117090/diff/ Testing --- Thanks, Jonathan Riddell
Re: Moving Milou to Extragear
Vishesh HandaOn Friday, February 14, 2014 01:09:19 PM wrote: On Thursday, February 13, 2014 11:28:40 AM Burkhard Lück wrote: That loads the translation catalog, which also contains messages from the plasmoid outside the library. Apparently that happens early enough at runtime (at least I see the catalog is loaded running milou in plasmoidviewer in locale x-test), so even messages used only in the plasmoid are translated. Your plasmoid tries to load a catalog named plasma_applet_milou_applet via plasmoid/applet.h:60:K_EXPORT_PLASMA_APPLET(milou_applet, Applet), but you extract to milou, so this catalog does not exist. But then the milou catalog would be loaded so the translations should be there, right? If not, what would be the correct way of fixing this? One option which I can think of is extracting the translations to plasma_applet_milou_applet, and updating the KCatalogLoader in the case the library is used without the applet. I've changed the catalog name to plasma_applet_milou_applet. That should work. I'm going to request the move to extragear on Monday. -- Vishesh Handa
Review Request 117157: Unlock session via DBus
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Changes --- How I tested it. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing (updated) --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:02 p.m., Thomas Lübking wrote: what is the valid (read: not malicious) usecase for this? i'd rather say that if quitting the greeter to exit the lock w/o password, that should be fixed to *not* exit the lock w/o password provision. There are some usecases mentioned in the bug I referenced. I can add another one: imagine that you are hosting, say, a programming competition (like ACM ICPC). You've got a room of PCs, they are locked before the contest. When the contest starts you want to unlock them all simultaneously instead of having contestants enter passwords by hands. - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54536 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. - Martin Gräßlin On March 29, 2014, 12:58 p.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 12:58 p.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. You have to authenticate anyway to access the DBus session bus. - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 1:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 12:58 p.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 12:58 p.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. Martin Gräßlin wrote: and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). Thomas Lübking wrote: you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking) this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special knowwhatido key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself) If you've installed your evil software you already have a thousand of ways of accessing the system. My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter. - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 1:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. Martin Gräßlin wrote: and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). Thomas Lübking wrote: you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking) this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special knowwhatido key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself) Kirill Elagin wrote: If you've installed your evil software you already have a thousand of ways of accessing the system. My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter. no, the lockscreen is secure. If you are logged in at a tty there is no way to unlock the screen - the only way to bypass the lock is to kill ksmserver which results in the session being killed. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 12:58 p.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 12:58 p.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. Martin Gräßlin wrote: and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). Thomas Lübking wrote: you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking) this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special knowwhatido key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself) Kirill Elagin wrote: If you've installed your evil software you already have a thousand of ways of accessing the system. My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter. Martin Gräßlin wrote: no, the lockscreen is secure. If you are logged in at a tty there is no way to unlock the screen - the only way to bypass the lock is to kill ksmserver which results in the session being killed. It seems to me that it's not secure actually. If you have a look at the bug I mentioned, you'll see a one-liner that unlocks the screen, right? Unfortunately I'm not really familiar with KDE internals, but I don't see any way to avoid this. (I should point out that, still, I don't see this as a security issue; once an $evilagent got your shell, you already lost, because now he can _modify memory_ of any of your processes, including ksmserver.) But if you still don't agree… well, will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` that triggers this behaviour? - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 117157: Unlock session via DBus
On March 29, 2014, 12:05 p.m., Martin Gräßlin wrote: I also have problems imagining what a use case for this is and I consider this as a security issue. It basically means that the session can get unlocked without going through authentication. Kirill Elagin wrote: You have to authenticate anyway to access the DBus session bus. Martin Gräßlin wrote: and running applications? It would allow $evilsecretservice to unlock the screen when $agent needs to use the system after remote installing some software. Since Snowden this doesn't sound so far fetched any more (unfortunately). Thomas Lübking wrote: you need access to a random shell of that user (what does not imply you actively logged into it), but can expose another session that pot. allows access to other logins (mail, webservices, even banking) this should (by default) no way be possible. any way to circumvent authentication to this very session should be guarded by a special knowwhatido key or require active authentication (ie. passing the pass hash via dbus - what's insecure enough by itself) Kirill Elagin wrote: If you've installed your evil software you already have a thousand of ways of accessing the system. My point is: if you've got privileges to issue this DBus call, you already have privileges to bypass the lockscreen. This is just a _sane_ way of doing so, because if you're an $evilagent you don't care how many lines of shell code it will take you to bypass the lockscreen, but if you are the user, it starts to matter. Martin Gräßlin wrote: no, the lockscreen is secure. If you are logged in at a tty there is no way to unlock the screen - the only way to bypass the lock is to kill ksmserver which results in the session being killed. Kirill Elagin wrote: It seems to me that it's not secure actually. If you have a look at the bug I mentioned, you'll see a one-liner that unlocks the screen, right? Unfortunately I'm not really familiar with KDE internals, but I don't see any way to avoid this. (I should point out that, still, I don't see this as a security issue; once an $evilagent got your shell, you already lost, because now he can _modify memory_ of any of your processes, including ksmserver.) But if you still don't agree… well, will it be acceptable to have an option in `kscreensaverrc` or `ksmserverrc` that triggers this behaviour? It seems to me that it's not secure actually. As pointed out in the very first comment, i consider this a serious bug and security issue - yes. FTR: There's a difference between the ability to poke memory on the one hand and have a nice GUI access to your money accounts, an open ssl session or root shell of a running system. Accessing random shells/client conections of the current session is the pot. privilegue escalation here, open to an attacker how could eg. not manipulate the software stack. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/#review54538 --- On March 29, 2014, 11:58 a.m., Kirill Elagin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117157/ --- (Updated March 29, 2014, 11:58 a.m.) Review request for kde-workspace. Bugs: 314989 http://bugs.kde.org/show_bug.cgi?id=314989 Repository: kde-workspace Description --- Unlock session via DBus Make org.freedesktop.ScreenSaver.SetActive(false) unlock session. Diffs - plasma-workspace/ksmserver/screenlocker/interface.cpp ecb30a37b1a207cf9dab8c53b1b879108a99a45b plasma-workspace/ksmserver/screenlocker/ksldapp.h b292b62f4df073fff31bcbfd0e39f4c4fe04c92d plasma-workspace/ksmserver/screenlocker/ksldapp.cpp f2e5262524447e8ae1df1fbf6543297c3be3e6b8 Diff: https://git.reviewboard.kde.org/r/117157/diff/ Testing --- I've tested this with KDE 4.11.5 which I'm currently running. Rebasing to master was completely trivial; I've looked through the code and I believe all the assumptions I made are still valid in master. Thanks, Kirill Elagin
Re: Review Request 112294: Implement multi-seat support in KDM
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112294/ --- (Updated March 29, 2014, 5:14 p.m.) Review request for kde-workspace and Oswald Buddenhagen. Changes --- Part one: fix trivial issues Repository: kde-workspace Description --- This patch implements dynamic multiseat in KDM. It follows the description in: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ In case systemd is no found at compile time, nothing changes. If logind is not running, nothing changes. If no additional seats have been configured (some Plugable USB-GPUs are automatically added as additional seats), nothing changes. In case there are additional seats beyond seat0, a reserved display is promoted to a local static one (and demoted if the seat is removed) and a new X-Server/greeter is spawned. The code has been tested extensively, with a combination of [Radeon dedicated GPU|Intel iGPU], [Intel iGPU|Displaylink USB GPU] and others. For history of this patch, see https://bugzilla.redhat.com/show_bug.cgi?id=884271 and https://bugzilla.redhat.com/show_bug.cgi?id=975079 Diffs (updated) - CMakeLists.txt d5c76d8 cmake/modules/CMakeLists.txt 117b3a5 kdm/backend/CMakeLists.txt 25f383f kdm/backend/client.c 26bb0b4 kdm/backend/dm.h b2f8c61 kdm/backend/dm.c 77a2ef7 kdm/backend/server.c d8dd6f3 kdm/backend/session.c 0e7901c Diff: https://git.reviewboard.kde.org/r/112294/diff/ Testing --- Single seat system, several multiseat systems Thanks, Stefan Brüns
Re: Review Request 112294: Implement multi-seat support in KDM
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112294/ --- (Updated March 29, 2014, 5:38 p.m.) Review request for kde-workspace and Oswald Buddenhagen. Changes --- readd FindSystemd.cmake (erroneously dropped), one more trivial fix Repository: kde-workspace Description --- This patch implements dynamic multiseat in KDM. It follows the description in: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ In case systemd is no found at compile time, nothing changes. If logind is not running, nothing changes. If no additional seats have been configured (some Plugable USB-GPUs are automatically added as additional seats), nothing changes. In case there are additional seats beyond seat0, a reserved display is promoted to a local static one (and demoted if the seat is removed) and a new X-Server/greeter is spawned. The code has been tested extensively, with a combination of [Radeon dedicated GPU|Intel iGPU], [Intel iGPU|Displaylink USB GPU] and others. For history of this patch, see https://bugzilla.redhat.com/show_bug.cgi?id=884271 and https://bugzilla.redhat.com/show_bug.cgi?id=975079 Diffs (updated) - CMakeLists.txt d5c76d8 cmake/modules/CMakeLists.txt 117b3a5 cmake/modules/FindSystemd.cmake PRE-CREATION kdm/backend/CMakeLists.txt 25f383f kdm/backend/client.c 26bb0b4 kdm/backend/dm.h b2f8c61 kdm/backend/dm.c 77a2ef7 kdm/backend/server.c d8dd6f3 kdm/backend/session.c 0e7901c Diff: https://git.reviewboard.kde.org/r/112294/diff/ Testing --- Single seat system, several multiseat systems Thanks, Stefan Brüns
Re: Review Request 112294: Implement multi-seat support in KDM
On March 28, 2014, 10:59 a.m., Oswald Buddenhagen wrote: kdm/backend/dm.c, line 1351 https://git.reviewboard.kde.org/r/112294/diff/2/?file=186612#file186612line1351 you can leave out the automatic multiseat won't be enabled from the followup messages. isn't there a function to turn the error code into a string? Regarding error codes, the calls are documented as: On failure, these calls return a negative errno-style error code. On March 28, 2014, 10:59 a.m., Oswald Buddenhagen wrote: kdm/backend/server.c, line 79 https://git.reviewboard.kde.org/r/112294/diff/2/?file=186613#file186613line79 why the redundant supply of the seat as a layout? There are no config matches taking the seat into account, so the only possibility to apply a specific config is to use layout. - Stefan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112294/#review54418 --- On March 29, 2014, 5:38 p.m., Stefan Brüns wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112294/ --- (Updated March 29, 2014, 5:38 p.m.) Review request for kde-workspace and Oswald Buddenhagen. Repository: kde-workspace Description --- This patch implements dynamic multiseat in KDM. It follows the description in: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ In case systemd is no found at compile time, nothing changes. If logind is not running, nothing changes. If no additional seats have been configured (some Plugable USB-GPUs are automatically added as additional seats), nothing changes. In case there are additional seats beyond seat0, a reserved display is promoted to a local static one (and demoted if the seat is removed) and a new X-Server/greeter is spawned. The code has been tested extensively, with a combination of [Radeon dedicated GPU|Intel iGPU], [Intel iGPU|Displaylink USB GPU] and others. For history of this patch, see https://bugzilla.redhat.com/show_bug.cgi?id=884271 and https://bugzilla.redhat.com/show_bug.cgi?id=975079 Diffs - CMakeLists.txt d5c76d8 cmake/modules/CMakeLists.txt 117b3a5 cmake/modules/FindSystemd.cmake PRE-CREATION kdm/backend/CMakeLists.txt 25f383f kdm/backend/client.c 26bb0b4 kdm/backend/dm.h b2f8c61 kdm/backend/dm.c 77a2ef7 kdm/backend/server.c d8dd6f3 kdm/backend/session.c 0e7901c Diff: https://git.reviewboard.kde.org/r/112294/diff/ Testing --- Single seat system, several multiseat systems Thanks, Stefan Brüns
Re: Review Request 112294: Implement multi-seat support in KDM
On March 28, 2014, 10:59 a.m., Oswald Buddenhagen wrote: kdm/backend/dm.c, line 1397 https://git.reviewboard.kde.org/r/112294/diff/2/?file=186612#file186612line1397 that seems questionable to me. why are you re-defining the display to be permanent? when the seat goes away, kdm won't know what to do with it. When a seat goes away, rStopDisplay(d, DS_RESERVE) is called - maybe a d-displayType = dLocal | dReserve is missing for these cases. But as long as the seat exists, you want it to behave like a static display (restart server after session exit), so dPermanent is IMHO correct. - Stefan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112294/#review54418 --- On March 29, 2014, 5:38 p.m., Stefan Brüns wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112294/ --- (Updated March 29, 2014, 5:38 p.m.) Review request for kde-workspace and Oswald Buddenhagen. Repository: kde-workspace Description --- This patch implements dynamic multiseat in KDM. It follows the description in: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ In case systemd is no found at compile time, nothing changes. If logind is not running, nothing changes. If no additional seats have been configured (some Plugable USB-GPUs are automatically added as additional seats), nothing changes. In case there are additional seats beyond seat0, a reserved display is promoted to a local static one (and demoted if the seat is removed) and a new X-Server/greeter is spawned. The code has been tested extensively, with a combination of [Radeon dedicated GPU|Intel iGPU], [Intel iGPU|Displaylink USB GPU] and others. For history of this patch, see https://bugzilla.redhat.com/show_bug.cgi?id=884271 and https://bugzilla.redhat.com/show_bug.cgi?id=975079 Diffs - CMakeLists.txt d5c76d8 cmake/modules/CMakeLists.txt 117b3a5 cmake/modules/FindSystemd.cmake PRE-CREATION kdm/backend/CMakeLists.txt 25f383f kdm/backend/client.c 26bb0b4 kdm/backend/dm.h b2f8c61 kdm/backend/dm.c 77a2ef7 kdm/backend/server.c d8dd6f3 kdm/backend/session.c 0e7901c Diff: https://git.reviewboard.kde.org/r/112294/diff/ Testing --- Single seat system, several multiseat systems Thanks, Stefan Brüns
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- Why not simply add a parameter to KApplication constructor? - Kirill Elagin On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Thomas Lübking wrote: Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? I've checked KApplication code and it seems that it creates a DBus service unconditionally. Which is pretty weird. Is that true that _every single_ application wants to be exposed via DBus? I guess, no. I wouldn't call this requirement “special” at all. I'm not sure about your freezing rules, but adding a parameter with a compatible default value shouldn't be a big deal, right? - Kirill --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Thomas Lübking wrote: Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? Kirill Elagin wrote: I've checked KApplication code and it seems that it creates a DBus service unconditionally. Which is pretty weird. Is that true that _every single_ application wants to be exposed via DBus? I guess, no. I wouldn't call this requirement “special” at all. I'm not sure about your freezing rules, but adding a parameter with a compatible default value shouldn't be a big deal, right? Is that true that _every single_ application wants to be exposed via DBus? No idea, but actually cannot think of other cases that don't want to. I do not expect a freeze exception for this at all, if you think it's reasonable you could propose it for KF5. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
Re: Review Request 117166: remove /MainApplication object from screenlocker greeter interface
On March 29, 2014, 8:39 p.m., Kirill Elagin wrote: Why not simply add a parameter to KApplication constructor? Thomas Lübking wrote: Being? I'm not aware of such parameter, kdelibs is semi-frozen and the requirement is also pretty special to add such feature to KApplication, yesno? Kirill Elagin wrote: I've checked KApplication code and it seems that it creates a DBus service unconditionally. Which is pretty weird. Is that true that _every single_ application wants to be exposed via DBus? I guess, no. I wouldn't call this requirement “special” at all. I'm not sure about your freezing rules, but adding a parameter with a compatible default value shouldn't be a big deal, right? Thomas Lübking wrote: Is that true that _every single_ application wants to be exposed via DBus? No idea, but actually cannot think of other cases that don't want to. I do not expect a freeze exception for this at all, if you think it's reasonable you could propose it for KF5. inb4 you ask: - new feature - api change - uncertain usecase - can easily be gained w/o api change/feature addition (pure convenience) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/#review54562 --- On March 29, 2014, 8:32 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117166/ --- (Updated March 29, 2014, 8:32 p.m.) Review request for kde-workspace, Martin Gräßlin and Kirill Elagin. Repository: kde-workspace Description --- Turned out it's possible to kquitapp the greeter w/o having to provide the desktop. whatever is the final resolution to bug #314989 resp. review #117157, ignorantly exposing the /MainApplication object on this process is certainly a bug. (I considered turning it into a QApplication, but that would have turned a HUGE patch and also the KDebug interface might be a benefit) As the issue exists since 4.10, i don't think it's necessary to press this into 4.11.8 (and break the workaround in bug #314989, which then can be reasonably resolved before 4.11.9) Diffs - ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 Diff: https://git.reviewboard.kde.org/r/117166/diff/ Testing --- locked screen, checked dbus interface of the greeter - MainApplication is gone. Thanks, Thomas Lübking
kde-workspace/master is frozen until split happens
Hello everybody, As Àlex Fiestas requested, I created the following repositories: - khotkeys - kinfocenter - kmenuedit - ksysguard - kwin - kwrited - libksysguard - oxygen - plasma-desktop - plasma-workspace - systemsettings - powerdevil All those projects are under kde/kde-workspace [1] except powerdevil which is in extragear/base [2] Note that kde-workspace/master is now frozen until the split happens [1] https://projects.kde.org/projects/kde/kde-workspace [2] https://projects.kde.org/projects/extragear/base Regards, Víctor Blázquez
Review Request 117174: Fix installing and removing desktop plasma theme packages.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/ --- Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure, and Ian Monroe. Bugs: 149479 http://bugs.kde.org/show_bug.cgi?id=149479 Repository: kdelibs Description --- Even though the bug appears RESOLVED it is not. Minor hack to packagestructure.cpp to search for the metadata.desktop file recursively. This helps with installing desktop themes and removing them. I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing themes ignore SoftSand for example, it's metadata.desktop is not properly formatted. There are others too which are not formatted which I guess could be fixed by setting a new format standard, maybe even a check package script to check new uploads on kde-look.org. Diffs - plasma/packagestructure.cpp 71148e1 Diff: https://git.reviewboard.kde.org/r/117174/diff/ Testing --- Compiled, run systemsettings, go to Desktop Themes, install / remove away. Some themes are broken so they won't work (not install). Thanks, Andrei Amuraritei
Review Request 117175: Fix installing new .comic packages from GHNS to appear in the installed packages list in the comic widget.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117175/ --- Review request for KDE Runtime, Albert Astals Cid, Aaron J. Seigo, Ian Monroe, and Lamarque Souza. Bugs: 306279 and 325028 http://bugs.kde.org/show_bug.cgi?id=306279 http://bugs.kde.org/show_bug.cgi?id=325028 Repository: kde-runtime Description --- When installing a new .comic provider from GHNS, it doesn't appear in the installed list on the comic widget. This fixes it. Diffs - plasma/tools/plasmapkg/main.cpp 61492fe Diff: https://git.reviewboard.kde.org/r/117175/diff/ Testing --- Compile, add new comic widget, install new comic providers. Thanks, Andrei Amuraritei
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 12:47:46 PM Lindsay Mathieson wrote: KDE 4.12.95 (Kubuntu 14.04 Beta 2) Is there work planned for this? because as is, its quite confusing and appears to be missing crucial settings. All I'm seeing is a Do not search in these locations' list of folder leaves. - For a start off, only listing the last section of the directory name will not do. People will have many folders all ending with the same leaf and its impossible to tell them apart with this. I disagree. I don't think people will have many different folders with the same names. And there always is the tooltip. I do have a similar bug report. Perhaps it would make sense to show the full path if there are 2 folders with the same name. I'm not sure. - A simple black list will not do. I need a white list - the ability to specify disjoint folders for indexing, not the other way around. And I'm sure the majority of people will be the same. What makes you say that? The old config allowed us to specify directories to index via a checklist tree, that worked really well. Some status info would be really useful to - number of files indexed etc. What use is there of that information? If you really want to know you can go to .local/share/baloo/file and run $ delve . -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 03:53:00 PM Shantanu Tushar Jha wrote: Last I checked, the list is as wide as the dialog and there is quite some space where a full path will (mostly) fit in, so it should be good. Also, is that bug reported on bugs.kde.org? https://bugs.kde.org/show_bug.cgi?id=332760 It's not about the width. The single folder looks much better and is less scarier. - A simple black list will not do. I need a white list - the ability to specify disjoint folders for indexing, not the other way around. And I'm sure the majority of people will be the same. What makes you say that? Well right now I don't know whether Baloo is indexing by root drive, and/or my home folder, and/or my other 2 disks, and/or my USB drive. Personally I'd like a whitelist because I'd like to command my desktop search to search at some places rather than it trying to search everything and me restricting it for some paths. The former makes you feel in command (TM). Isn't that just because you've bad experiences with Nepomuk? Also, I'd love to know what kind of files you don't want it to index. I understand source code, but what else? TBH, even I thought the dialog is WIP ;) What would you recommend? Apart from both white list and black lists, which I'm against. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 11:38:59 AM Vishesh Handa wrote: https://bugs.kde.org/show_bug.cgi?id=332760 It's not about the width. The single folder looks much better and is less scarier. Good grief. I can't believe you said that. Point me to a bug report of user list posting saying that directory paths are scary. The single folder looks much better Very much a matter of opinion. I think it looks dreadful, is ambiguous and confusing. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 11:17:45 AM you wrote: - A simple black list will not do. I need a white list - the ability to specify disjoint folders for indexing, not the other way around. And I'm sure the majority of people will be the same. What makes you say that? The more I think on it, the less useful it is to index the whole machine by default. For a start off there is a lot of content that make no sense to index - config files, scripts, web apps, all the binaries of course. And totally breaks on any machine with multiple user accounts, which is actually quite common, both for business and home usage. Peoples searchable content is generally stored under their home directories and/or on a file server, which again is not uncommon - lot of home NAS's out there now. Just specifying a default white list of the home dir covers that nicely and allows them to easily extend that for data and/or shares that might be mounted out of their home dir. If you really want to index every dir than you can just whitelist the root. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 11:38:59 AM Vishesh Handa wrote: What would you recommend? Apart from both white list and black lists, which I'm against. Why are you against them? considering you are using a blacklist. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 11:38:59 AM Vishesh Handa wrote: What would you recommend? Apart from both white list and black lists, I quite liked the old directory tree with check boxes. Flexible, clear and unambiguous. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 09:07:04 PM Lindsay Mathieson wrote: On Sat, 29 Mar 2014 11:17:45 AM you wrote: - A simple black list will not do. I need a white list - the ability to specify disjoint folders for indexing, not the other way around. And I'm sure the majority of people will be the same. What makes you say that? The more I think on it, the less useful it is to index the whole machine by default. For a start off there is a lot of content that make no sense to index - config files, scripts, web apps, all the binaries of course. We do not index everything. That would be foolhardy. We just index your HOME by default. And totally breaks on any machine with multiple user accounts, which is actually quite common, both for business and home usage. Peoples searchable content is generally stored under their home directories and/or on a file server, which again is not uncommon - lot of home NAS's out there now. Just specifying a default white list of the home dir covers that nicely and allows them to easily extend that for data and/or shares that might be mounted out of their home dir. That's exactly what is done right now. How about you have a look at the config file and the implementation? If you really want to index every dir than you can just whitelist the root. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 12:23:50 PM Vishesh Handa wrote: We do not index everything. That would be foolhardy. We just index your HOME by default. There's no indication of this on the config UI at al. So how do I index Paths that are out side my home dir, such as my /data dir? Just specifying a default white list of the home dir covers that nicely and allows them to easily extend that for data and/or shares that might be mounted out of their home dir. That's exactly what is done right now. You said it only black listed. How about you have a look at the config file and the implementation? I have no idea where it is. Would this be the reply for users who are scared of full directory paths? -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 12:23:50 PM Vishesh Handa wrote: That's exactly what is done right now. How about you have a look at the config file and the implementation? ~/.kde/share/config$/baloofilerc? Are there docs on its options? -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, Mar 29, 2014 at 5:13 PM, Vishesh Handa m...@vhanda.in wrote: On Saturday, March 29, 2014 09:27:29 PM Lindsay Mathieson wrote: On Sat, 29 Mar 2014 12:23:50 PM Vishesh Handa wrote: We do not index everything. That would be foolhardy. We just index your HOME by default. There's no indication of this on the config UI at al. So how do I index Paths that are out side my home dir, such as my /data dir? Just specifying a default white list of the home dir covers that nicely and allows them to easily extend that for data and/or shares that might be mounted out of their home dir. That's exactly what is done right now. You said it only black listed. From the UI - only black listing is available. As I said, please try it out and experiment. It does have sensible defaults. Here is how it currently works - * By default your HOME directory is indexed, and all other external mounts are are excluded. * The UI will show the list of all excluded mounts and excluded folders that have been manually added. So if you want some external mount to be indexed, just remove it from the blacklist. I had to read that ^ 3 times to understand what you are saying - probably a good enough indication already that its confusing. Also, I'm still confused how do I remove the external mount? You said only manually added folders will be there. How about you have a look at the config file and the implementation? I have no idea where it is. Would this be the reply for users who are scared of full directory paths? No. But it is my reply for when users complain without experimenting with what it currently does. Yes, we're lacking documentation, but we need more people to step up and help. There is only so much I can do. That is quite fair, I'm still at the first version of packages kubuntu had, stuff is still upgrading. Will test again and report. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 10:15:34 PM Lindsay Mathieson wrote: On Sat, 29 Mar 2014 12:43:06 PM Vishesh Handa wrote: Here is how it currently works - * By default your HOME directory is indexed, and all other external mounts are are excluded. * The UI will show the list of all excluded mounts and excluded folders that have been manually added. That makes more sense. But it does indicate why its import to show the full path - the leaf folder is not necessarily going to identify the mount at all, we have no idea what people are going to be setting up. So if you want some external mount to be indexed, just remove it from the blacklist. But my external mount is not under $HOME The external mount is not shown in the KCM? If it isn't then we need to fix that. Please run the following command - $ solid-hardware query 'Is StorageAccess' You will get a list of ids. You can get more info about each of them via - $ solid-hardware details 'id' | grep accessible We list the accessible ones in the KCM. Some fixed mounts such as /, /boot, /tmp and /home are ignored. Please see if your external mount satisfies this criteria. I took a look at baloofilerc and modified the include to this: folders[$e]=/data/,$HOME/ this includes multiple folders? -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 05:56:47 PM Shantanu Tushar Jha wrote: On Sat, Mar 29, 2014 at 4:08 PM, Vishesh Handa m...@vhanda.in wrote: On Saturday, March 29, 2014 03:53:00 PM Shantanu Tushar Jha wrote: Last I checked, the list is as wide as the dialog and there is quite some space where a full path will (mostly) fit in, so it should be good. Also, is that bug reported on bugs.kde.org? https://bugs.kde.org/show_bug.cgi?id=332760 It's not about the width. The single folder looks much better and is less scarier. - A simple black list will not do. I need a white list - the ability to specify disjoint folders for indexing, not the other way around. And I'm sure the majority of people will be the same. What makes you say that? Well right now I don't know whether Baloo is indexing by root drive, and/or my home folder, and/or my other 2 disks, and/or my USB drive. Personally I'd like a whitelist because I'd like to command my desktop search to search at some places rather than it trying to search everything and me restricting it for some paths. The former makes you feel in command (TM). Isn't that just because you've bad experiences with Nepomuk? Also, I'd love to know what kind of files you don't want it to index. I understand source code, but what else? Nope*, in fact, Nepomuk lets me clearly control (and see) what is indexed and what is not. Also, I dont want to index source code, VM images, etc etc for which Baloo probably has excludes but I also don't want to index files on external storage (like random flash drives I insert). But, I should still be able to do so for devices I choose (a USB hard disk which I always keep connected). All of this is supported. On a note, I like that you want to simplify the UI but please take care that you don't remove actually useful features. It is important because almost all of KDE users want at least basic configuration; they'd be using something like GNOME if they didn't. Agreed, but I don't think I've removed useful features. Feel free to take the old nepomuk KCM code and make it into a Baloo Index Tweaking application. The backend code still supports all the features that you seem to want. It's not a priority for me right now, but it would be really nice to have. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 01:43:46 PM Vishesh Handa wrote: Feel free to take the old nepomuk KCM code and make it into a Baloo Index Tweaking application. The backend code still supports all the features that you seem to want. Fair enough. Would you know which repo/module it lives in? -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 06:04:09 PM Shantanu Tushar Jha wrote: I had to read that ^ 3 times to understand what you are saying - probably a good enough indication already that its confusing. Also, I'm still confused how do I remove the external mount? You said only manually added folders will be there. If you have external media which should be shown, they will appear. Eg - I just plugged in a pen-drive, and opened the KCM - http://vhanda.in/baloo_kcm.png -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 01:40:58 PM Vishesh Handa wrote: The external mount is not shown in the KCM? If it isn't then we need to fix that. Please run the following command - $ solid-hardware query 'Is StorageAccess' You will get a list of ids. You can get more info about each of them via - $ solid-hardware details 'id' | grep accessible We list the accessible ones in the KCM. Some fixed mounts such as /, /boot, /tmp and /home are ignored. Please see if your external mount satisfies this criteria. I'm confused - the external mount is shown, but I actually want it to be indexed, so I removed it, as far as I understand from what you are saying, only items under $HOME are indexed, but my data lives under /data, not $HOME (/home/lindsay). -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 10:51:06 PM Lindsay Mathieson wrote: I'm confused - the external mount is shown, but I actually want it to be indexed, so I removed it, as far as I understand from what you are saying, only items under $HOME are indexed, but my data lives under /data, not $HOME (/home/lindsay). Alright. I'm probably not being very clear. It's hard explaining stuff when you already know everything about it. Let me try this in a simpler manner - Default Settings: Only $HOME is in the white-list and eternal media is in the black-list If you remove the external media from the black-list, then it goes in the white list and is going to be indexed. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 02:04:11 PM Vishesh Handa wrote: If you remove the external media from the black-list, then it goes in the white list and is going to be indexed. Ok, seems a bit complicated and black magic - I'd prefer to explicitly set directories rather then hope the software guesses right. What defines external media? my /data mount is not on a external USB drive, its an internal sata drive mounted at boot. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat 29, March 23:03:34 Lindsay Mathieson wrote: Ok, seems a bit complicated and black magic - I'd prefer to explicitly set directories rather then hope the software guesses right. At the beginning I was with you: I thought we need a white list and not the other way around and I thought we need filters too, but after I read Vishesh responses I guess he's right. We had a bad experience with Nepomuk and now we want to control everything about this new desktop search settings, but we don't have to. We don't need to filter out source code, it already does. We don't need to black list external devices, it already does. It just works out of the box. I guess we can stop to worry about desktop search anymore. My 2 cents. -- Andrea Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, Mar 29, 2014 at 6:34 PM, Vishesh Handa m...@vhanda.in wrote: On Saturday, March 29, 2014 10:51:06 PM Lindsay Mathieson wrote: I'm confused - the external mount is shown, but I actually want it to be indexed, so I removed it, as far as I understand from what you are saying, only items under $HOME are indexed, but my data lives under /data, not $HOME (/home/lindsay). Alright. I'm probably not being very clear. It's hard explaining stuff when you already know everything about it. Let me try this in a simpler manner - Default Settings: Only $HOME is in the white-list and eternal media is in the black-list If you remove the external media from the black-list, then it goes in the white list and is going to be indexed. Ok I plugged in my OtherDisk and it seems to work as you said, then I removed the OtherDisk from the blacklist. Once I do that, there is no way to know what is in fact being indexed. If you are hell bent on not allowing a whitelist, can you at least provide a way for the user to know what is being indexed? Like- Currently indexing- Your home directory (/home/shantanu) OtherDisk Another suggestion, provide a tooltip for the Developer mode thing, I've no idea what it does. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, Mar 29, 2014 at 6:48 PM, Andrea Scarpino scarp...@kde.org wrote: On Sat 29, March 23:03:34 Lindsay Mathieson wrote: Ok, seems a bit complicated and black magic - I'd prefer to explicitly set directories rather then hope the software guesses right. At the beginning I was with you: I thought we need a white list and not the other way around and I thought we need filters too, but after I read Vishesh responses I guess he's right. We had a bad experience with Nepomuk and now we want to control everything about this new desktop search settings, but we don't have to. We don't need to filter out source code, it already does. We don't need to black list external devices, it already does. It just works out of the box. I guess we can stop to worry about desktop search anymore. I find it very impractical to believe that we can cover each and every file type every user in the world will like to exclude. Having sane defaults is one thing, not allowing to change those* when in need is plain wrong. * And I am not taking editing config files as a solution if what we are targeting here is making things easy for the user. My 2 cents. -- Andrea Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 02:18:24 PM Andrea Scarpino wrote: We had a bad experience with Nepomuk and now we want to control everything about this new desktop search settings, but we don't have to. We don't need to filter out source code, it already does. We don't need to black list external devices, it already does. It just works out of the box. Except when it doesn't. I don't like this automagic stuff. There's bound to be edge cases where it doesn't work, possibly quite a lot of them. And all those user who encounter them will have no way of knowing whats happening and will just squawk loudly and often that search is still broken. To me, it looks like taking something simple - indexing a collection of directories, and over thinking/making it really complicated. I think you'd be better off keeping it simple and letting the user decide what they want indexed. I guess we can stop to worry about desktop search anymore. I currently have no idea what is being indexed on my pc. I have no way of finding out. If I change my directory structure or add extra media mounts I just have to have faith that baloo does the right thing. It just seems a recipe for user angst and frustration. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 06:48:45 PM Shantanu Tushar Jha wrote: Ok I plugged in my OtherDisk and it seems to work as you said, then I removed the OtherDisk from the blacklist. Once I do that, there is no way to know what is in fact being indexed. If you are hell bent on not allowing a whitelist, can you at least provide a way for the user to know what is being indexed? Like- Currently indexing- Your home directory (/home/shantanu) OtherDisk Yeah. Perhaps. What I was really trying to do was hide the concept of indexing from the user. They care about searching, not about indexing. That's why the Systems settings says Desktop Search and Hide from search results. Another suggestion, provide a tooltip for the Developer mode thing, I've no idea what it does. I've removed the Developer mode. You might want to try out RC1. It has many important fixes. Actually, maybe you should just compile baloo on your own - KDE/4.13. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday, March 29, 2014 11:34:36 PM Lindsay Mathieson wrote: On Sat, 29 Mar 2014 02:18:24 PM Andrea Scarpino wrote: We had a bad experience with Nepomuk and now we want to control everything about this new desktop search settings, but we don't have to. We don't need to filter out source code, it already does. We don't need to black list external devices, it already does. It just works out of the box. Except when it doesn't. I don't like this automagic stuff. There's bound to be edge cases where it doesn't work, possibly quite a lot of them. And all those user who encounter them will have no way of knowing whats happening and will just squawk loudly and often that search is still broken. In those cases they can report bugs and we can fix it. I would really like if you could bring many of these edge cases. Lets try to find a solution? I guess we can stop to worry about desktop search anymore. I currently have no idea what is being indexed on my pc. I have no way of finding out. If I change my directory structure or add extra media mounts I just have to have faith that baloo does the right thing. It just seems a recipe for user angst and frustration. I'm not sure if this is the way you intended it, but to me this translates to - I have no trust in the software you have written and would like to check every thing it is doing, and I expect you to provide user interfaces so that I can monitor it every second -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 03:00:36 PM Vishesh Handa wrote: What I was really trying to do was hide the concept of indexing from the user. They care about searching, not about indexing. You've surveyed users on this? have some data? Users care about results and confidence in those results. Information on what is indexed improves this. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, Mar 29, 2014 at 7:45 PM, Shantanu Tushar Jha shaan...@gmail.comwrote: On Sat, Mar 29, 2014 at 7:30 PM, Vishesh Handa m...@vhanda.in wrote: On Saturday, March 29, 2014 06:48:45 PM Shantanu Tushar Jha wrote: Ok I plugged in my OtherDisk and it seems to work as you said, then I removed the OtherDisk from the blacklist. Once I do that, there is no way to know what is in fact being indexed. If you are hell bent on not allowing a whitelist, can you at least provide a way for the user to know what is being indexed? Like- Currently indexing- Your home directory (/home/shantanu) OtherDisk Yeah. Perhaps. What I was really trying to do was hide the concept of indexing from the user. They care about searching, not about indexing. However, the problem is that most of your userbase is (unfortunately, in this case) smart and will get confused if search magically happens without indexing. That's why the Systems settings says Desktop Search and Hide from search results. Then it can say Searching in instead in Indexing in or, better Search In Another suggestion, provide a tooltip for the Developer mode thing, I've no idea what it does. I've removed the Developer mode. You might want to try out RC1. It has many important fixes. Actually, maybe you should just compile baloo on your own - KDE/4.13. -- Vishesh Handa -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Samstag, 29. März 2014 15:09:10 CEST, Vishesh Handa wrote: I currently have no idea what is being indexed on my pc. I have no way of finding out. If I change my directory structure or add extra media mounts I just have to have faith that baloo does the right thing. It just seems a recipe for user angst and frustration. I'm not sure if this is the way you intended it, but to me this translates to - I have no trust in the software you have written and would like to check every thing it is doing, and I expect you to provide user interfaces so that I can monitor it every second To me it translates to the simple fact that I doubt that other people know what i want/need to be indexed and i'd like to know and control what is indexed on MY box, so don't try to turn it into a techinal insult, that's ridiculous. You /cannot/ do it right since you /cannot/ know what is right in the first place. That's not a technical issue. Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 03:21:26 PM Thomas Lübking wrote: To me it translates to the simple fact that I doubt that other people know what i want/need to be indexed and i'd like to know and control what is indexed on MY box, so don't try to turn it into a techinal insult, that's ridiculous. You /cannot/ do it right since you /cannot/ know what is right in the first place. That's not a technical issue. Exactly this. I'm not trying to cast aspersions on your abilities Vishesh, baloo is whats needed for KDE, what nepomuk was meant to be, and its come together brilliantly. You're trying to engineer the baloo config to be automatic for everyone and it just can't be done. Better to leave it bare and simple initially, and see what happens in userland. It might shake out quite differently to what you expect. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 03:09:10 PM Vishesh Handa wrote: In those cases they can report bugs and we can fix it. I would really like if you could bring many of these edge cases. Lets try to find a solution? If we knew them ahead of time they wouldn't be edge cases. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sunday, March 30, 2014 12:30:55 AM Lindsay Mathieson wrote: On Sat, 29 Mar 2014 03:21:26 PM Thomas Lübking wrote: To me it translates to the simple fact that I doubt that other people know what i want/need to be indexed and i'd like to know and control what is indexed on MY box, so don't try to turn it into a techinal insult, that's ridiculous. You /cannot/ do it right since you /cannot/ know what is right in the first place. That's not a technical issue. Exactly this. I'm not trying to cast aspersions on your abilities Vishesh, baloo is whats needed for KDE, what nepomuk was meant to be, and its come together brilliantly. You're trying to engineer the baloo config to be automatic for everyone and it just can't be done. Better to leave it bare and simple initially, and see what happens in userland. It might shake out quite differently to what you expect. Alright. Perhaps I'm over reacting :) I'll bring this up with the usability team, and ask for help. -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, Mar 29, 2014 at 9:58 PM, Vishesh Handa m...@vhanda.in wrote: On Sunday, March 30, 2014 12:30:55 AM Lindsay Mathieson wrote: On Sat, 29 Mar 2014 03:21:26 PM Thomas Lübking wrote: To me it translates to the simple fact that I doubt that other people know what i want/need to be indexed and i'd like to know and control what is indexed on MY box, so don't try to turn it into a techinal insult, that's ridiculous. You /cannot/ do it right since you /cannot/ know what is right in the first place. That's not a technical issue. Exactly this. I'm not trying to cast aspersions on your abilities Vishesh, baloo is whats needed for KDE, what nepomuk was meant to be, and its come together brilliantly. You're trying to engineer the baloo config to be automatic for everyone and it just can't be done. Better to leave it bare and simple initially, and see what happens in userland. It might shake out quite differently to what you expect. Alright. Perhaps I'm over reacting :) I'll bring this up with the usability team, and ask for help. *hugs* :) -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
kde-workspace/master is frozen until split happens
Hello everybody, As Àlex Fiestas requested, I created the following repositories: - khotkeys - kinfocenter - kmenuedit - ksysguard - kwin - kwrited - libksysguard - oxygen - plasma-desktop - plasma-workspace - systemsettings - powerdevil All those projects are under kde/kde-workspace [1] except powerdevil which is in extragear/base [2] Note that kde-workspace/master is now frozen until the split happens [1] https://projects.kde.org/projects/kde/kde-workspace [2] https://projects.kde.org/projects/extragear/base Regards, Víctor Blázquez Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Dumb question re nepomuk
Given we have baloo now, should I still be building nepomuk-core nepomuk- widgets? I'm unclear as to whether baloo is a replacement for nepomuk or a new backend for it. thanks, -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Sat, 29 Mar 2014 05:28:16 PM Vishesh Handa wrote: You're trying to engineer the baloo config to be automatic for everyone and it just can't be done. Better to leave it bare and simple initially, and see what happens in userland. It might shake out quite differently to what you expect. BTW, that is just my opinion of course, not fact. I should be more tactful in that regard. With regard to only showing the end leaf of a directory in the exclusion list and the auto adding of paths, after reviewing your explanations of how it works and your examples, it seems to me we've been viewing it from different use cases. I'm focussed on inclusions/exclusions of static local directories, whereas your examples seem to be more concerned with the dynamic adding/removal of external drives (USB etc). I'm guessing your patterning it on something like the places panel in Dolphin where drives will appear/disappear dynamically. In that context it makes send to only display the last leaf, though I think what Dolphin actually shows is the volume name. cheers, -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Dumb question re nepomuk
On Sunday, March 30, 2014 09:36:39 AM Lindsay Mathieson wrote: Given we have baloo now, should I still be building nepomuk-core nepomuk- widgets? You don't need to build it any more. However, the nepomuk-baloo migrator is in nepomuk-core. It only needs to be run once. I'm unclear as to whether baloo is a replacement for nepomuk or a new backend for it. Replacement. thanks, -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Some more baloo control questions
1. Is the baloo file index stored at: ~.kde/share/apps/baloo/file/ ? 2. Would deleting the above directory be sufficient to fore a reindex of my content? 3. Is there a way to control the baloo process so I can stop/start it? there does not appear to be a nepomukctl equivalent. The reason for the above questions. All my content that was indexed prior to today is not longer findable by baloo. New content I create is, both by filename and content. I can only presume that the db has been corrupted and old content is no longer in it, but its also not being re-indexed. This is why info on the index is important. I have no way of seeing what or how much is indexed - a simple file count would tell me a lot. I have no way of maintaining the db short of erasing it, and no way controlling the indexing process. Crashes happen. Weird shit happens. We can't assume it doesn't. -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Systems Settings - Desktop Search
On Saturday 29 March 2014 15:00:36 Vishesh Handa wrote: On Saturday, March 29, 2014 06:48:45 PM Shantanu Tushar Jha wrote: Ok I plugged in my OtherDisk and it seems to work as you said, then I removed the OtherDisk from the blacklist. Once I do that, there is no way to know what is in fact being indexed. If you are hell bent on not allowing a whitelist, can you at least provide a way for the user to know what is being indexed? Like- Currently indexing- Your home directory (/home/shantanu) OtherDisk Yeah. Perhaps. What I was really trying to do was hide the concept of indexing from the user. They care about searching, not about indexing. That's why the Systems settings says Desktop Search and Hide from search results. Does it really say hide from search results? This user assumes that translates to Its still indexed, you just won't see the results from that. Which would not give me much confidence. Because i understand the difference between search results and index. Mike Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
[Kde-hardware-devel] Loop device description return by udisks2 backend
Hello, I was looking a way to change the name of the loop device found in dolphin's place panel. I found it's solid udisks2 backend which return an hard coded description in backends/udisks2/udisksdevice.cpp line 254 : if (isLoop()) return QObject::tr(Loop Device); Is there any raison to hard coding this ? I just try to change by this : if (isLoop()) return volumeDescription(); And i get the label found by the udisksctl command line when i mounted an iso file (udf) and also i get the label display in the dolphin's place panel. I don't really know if this is the right way to modify this. I don't really know about c++ coding. See small patch attached. Sorry for my poor english, hope you understand me This is solid in kde (libs) 4.12.3. Thanks ! --- udisksdevice.cpp 2014-02-28 00:04:10.0 +0100 +++ udisksdevice.cpp.new 2014-03-27 16:53:18.865813003 +0100 @@ -251,7 +251,7 @@ return hintName; if (isLoop()) -return QObject::tr(Loop Device); +return volumeDescription(); else if (isSwap()) return QObject::tr(Swap Space); else if (queryDeviceInterface(Solid::DeviceInterface::StorageDrive)) ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[Kde-hardware-devel] Review Request 117164: Fix compilation with -DWITH_SOLID_UDISKS2=OFF
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117164/ --- Review request for Solid. Repository: solid Description --- This patch adds formerly missing includes, sot that the code compiles again. Diffs - src/solid/backends/udisks/udisksstorageaccess.cpp d58fea8 Diff: https://git.reviewboard.kde.org/r/117164/diff/ Testing --- I've run make test; all 3 tests still passed. Thanks, Fabian Kosmale ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
