Re: Review Request 115717: Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set
On Feb. 19, 2014, 3:07 p.m., Alex Merry wrote: I don't think papering over the X11-ness of kdesu like this is the right approach. Of course, what this framework really needs is a test app; maybe a simple port of the kdesu app from kde-runtime? Kevin Ottens wrote: This kind of papering over can only be temporary indeed. Just wondering if Martin has the possibility to clean that up better at that stage? As for the test app: hell yes, definitely needed. Martin Gräßlin wrote: well yes if there's a testapp and that works I can implement it properly. But IIRC kdesu never worked on my setup (not having a password for root). Kevin Ottens wrote: You can use it for other users than root you know. ;-) Martin Gräßlin wrote: no, I didn't and which other users? ;-) Kevin Ottens wrote: My point is that if you need to test it's trivial to add a temporary user... Kevin Ottens wrote: So what do we do of this patch? Any chance of a test app? Any chance of a test app? I would prefer if the test app could be integrated by a domain expert. I do not really feel comfortable about it. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/#review50240 --- On Feb. 13, 2014, 10:41 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/ --- (Updated Feb. 13, 2014, 10:41 a.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set If kdesu is compiled with X11 it required the DISPLAY variable to be set. This is no longer correct as it might have been compiled with X11 but is run on Wayland. Thus the code checks now also for WAYLAND_DISPLAY in the HAVE_X11 ifdef blocks. The Wayland support should become more complete, I do not know how it behaves if we compile without X11 support. Unfortunately there are no autotests and no test applications which one could use. Diffs - src/client.cpp 91bfd78fbca6e5d8d365d924c0260087e3937948 src/kcookie.cpp 59448351696c503b34b7507e9c3fa8efc53139f9 Diff: https://git.reviewboard.kde.org/r/115717/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116766: Use a desktop file we might find for testing KServiceActions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116766/#review52874 --- It would have been better to just put a local copy of that desktop file into the kservice autotests subdir, so that it's always available to run the test on. Now we depend on konsolerun.desktop which might change in the future, etc. And this way we can add stuff to the desktop file to test more Actions features in the future. - David Faure On March 12, 2014, 3:47 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116766/ --- (Updated March 12, 2014, 3:47 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Use a desktop file we might find for testing KServiceActions The screensaver stuff isn't ported to frameworks 5 yet, so looking for those desktop files won't work. This uses something that might actually be installed instead. Diffs - autotests/kservicetest.h aa1c691c75c9e5b6903bcbf6e2dc95809ee1ce21 autotests/kservicetest.cpp 711fb9b649e580ad474b0cdecd26dcdbfdc302a2 Diff: https://git.reviewboard.kde.org/r/116766/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116747: Clean up KCompletionBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/#review52881 --- src/kcompletionbox.cpp https://git.reviewboard.kde.org/r/116747/#comment37230 Is this comment definitely no longer relevant? It looks like it refers to the sendPostedEvents() call that's still there. - Alex Merry On March 12, 2014, 10:57 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/ --- (Updated March 12, 2014, 10:57 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Clean up KCompletionBox -canceled() - cancelled (private method) -Deprecate sizeAndPosition() -- resizeAndReposition() -Remove old comments and commented-out code -Move some slots to be normal methods, since they don't seem to be able to work as slots. Diffs - src/kcompletionbox.h 09b7527 src/kcompletionbox.cpp 92e87b3 Diff: https://git.reviewboard.kde.org/r/116747/diff/ Testing --- It builds and tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116766: Use a desktop file we might find for testing KServiceActions
On March 13, 2014, 8:41 a.m., David Faure wrote: It would have been better to just put a local copy of that desktop file into the kservice autotests subdir, so that it's always available to run the test on. Now we depend on konsolerun.desktop which might change in the future, etc. And this way we can add stuff to the desktop file to test more Actions features in the future. Yeah, I vaguely intended to move to that in the future; I mostly made this change so I could check that some other changes *really* didn't break any tests. But I'll look at doing that change up front. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116766/#review52874 --- On March 12, 2014, 3:47 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116766/ --- (Updated March 12, 2014, 3:47 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Use a desktop file we might find for testing KServiceActions The screensaver stuff isn't ported to frameworks 5 yet, so looking for those desktop files won't work. This uses something that might actually be installed instead. Diffs - autotests/kservicetest.h aa1c691c75c9e5b6903bcbf6e2dc95809ee1ce21 autotests/kservicetest.cpp 711fb9b649e580ad474b0cdecd26dcdbfdc302a2 Diff: https://git.reviewboard.kde.org/r/116766/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116766: Use a desktop file we might find for testing KServiceActions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116766/ --- (Updated March 13, 2014, 11:27 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Use a desktop file we might find for testing KServiceActions The screensaver stuff isn't ported to frameworks 5 yet, so looking for those desktop files won't work. This uses something that might actually be installed instead. Diffs - autotests/kservicetest.h aa1c691c75c9e5b6903bcbf6e2dc95809ee1ce21 autotests/kservicetest.cpp 711fb9b649e580ad474b0cdecd26dcdbfdc302a2 Diff: https://git.reviewboard.kde.org/r/116766/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116781: List catalog from all install dirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/ --- Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This makes sure that if XDG_DATA_DIRS contains kde4support install prefix and then kdoctools install prefix, then kdoctools catalogs are listed nevertheless. Should fix build of kde-workspace and kate on build.kde.org. Diffs - src/xslt.cpp 6d5819e Diff: https://git.reviewboard.kde.org/r/116781/diff/ Testing --- Rebuilt kde-runtime (was failing there), kate and kde-workspace. No build failures. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116781: List catalog from all install dirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/#review52886 --- Ship it! Thank you; I can't test now but it looks sane; as a suggestion, I would explicitly mention that this is for environments where each module is installed using a different prefix as I wrote in the related commit (for https://git.reviewboard.kde.org/r/116670/). - Luigi Toscano On March 13, 2014, 12:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/ --- (Updated March 13, 2014, 12:59 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This makes sure that if XDG_DATA_DIRS contains kde4support install prefix and then kdoctools install prefix, then kdoctools catalogs are listed nevertheless. Should fix build of kde-workspace and kate on build.kde.org. Diffs - src/xslt.cpp 6d5819e Diff: https://git.reviewboard.kde.org/r/116781/diff/ Testing --- Rebuilt kde-runtime (was failing there), kate and kde-workspace. No build failures. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116781: List catalog from all install dirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/ --- (Updated March 13, 2014, 1:47 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Changes --- Improve comment. Repository: kdoctools Description --- This makes sure that if XDG_DATA_DIRS contains kde4support install prefix and then kdoctools install prefix, then kdoctools catalogs are listed nevertheless. Should fix build of kde-workspace and kate on build.kde.org. Diffs (updated) - src/xslt.cpp 6d5819e Diff: https://git.reviewboard.kde.org/r/116781/diff/ Testing --- Rebuilt kde-runtime (was failing there), kate and kde-workspace. No build failures. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116781: List catalog from all install dirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/#review52890 --- This review has been submitted with commit 02478b34df416862c50da8186742491bd29012e8 by Aurélien Gâteau to branch master. - Commit Hook On March 13, 2014, 12:47 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/ --- (Updated March 13, 2014, 12:47 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This makes sure that if XDG_DATA_DIRS contains kde4support install prefix and then kdoctools install prefix, then kdoctools catalogs are listed nevertheless. Should fix build of kde-workspace and kate on build.kde.org. Diffs - src/xslt.cpp 6d5819e Diff: https://git.reviewboard.kde.org/r/116781/diff/ Testing --- Rebuilt kde-runtime (was failing there), kate and kde-workspace. No build failures. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116781: List catalog from all install dirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116781/ --- (Updated March 13, 2014, 1:01 p.m.) Status -- This change has been marked as submitted. Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This makes sure that if XDG_DATA_DIRS contains kde4support install prefix and then kdoctools install prefix, then kdoctools catalogs are listed nevertheless. Should fix build of kde-workspace and kate on build.kde.org. Diffs - src/xslt.cpp 6d5819e Diff: https://git.reviewboard.kde.org/r/116781/diff/ Testing --- Rebuilt kde-runtime (was failing there), kate and kde-workspace. No build failures. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kdoctools_master_qt5 #38
See http://build.kde.org/job/kdoctools_master_qt5/38/changes Changes: [agateau] List catalog from all install dirs -- 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/kdoctools_master_qt5/ws/ Running Prebuild steps [kdoctools_master_qt5] $ /bin/sh -xe /tmp/hudson6887938633212081990.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/kdoctools 5c6ada2..02478b3 master - origin/master * [new tag] v4.97.0- v4.97.0 Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 5c6ada2 Fix installing on Windows Removing build/ Removing dotdata/ Removing install/ Success build forhudson.tasks.Shell@3a256540 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/kdoctools Checking out Revision 02478b34df416862c50da8186742491bd29012e8 (refs/heads/jenkins) Run condition [File exists] enabling prebuild for step [Publish JUnit test result report] Run condition [File exists] enabling prebuild for step [Publish Cppcheck results] [kdoctools_master_qt5] $ /bin/sh -xe /tmp/hudson2416363039616394716.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: kdoctools - Branch master == Build Dependencies: cmake - Branch master qt5 - Branch stable karchive - Branch master extra-cmake-modules - Branch master == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.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 -- Found LibXslt: /usr/lib64/libxslt.so (found version 1.1.28) -- Found LibXml2: /usr/lib64/libxml2.so (found version 2.9.0) -- Found DocBookXML4: /usr/share/xml/docbook/schema/dtd/4.5 (Required is at least version 4.5) -- Found DocBookXSL: /usr/share/xml/docbook/stylesheet/nwalsh/current -- Looking for include file stdio.h -- Looking for include file stdio.h - found -- Looking for include file stdlib.h -- Looking for include file stdlib.h - found -- Looking for include file sys/types.h -- Looking for include file sys/types.h - found -- Looking for include file sys/stat.h -- Looking for include file sys/stat.h - found -- -- The following REQUIRED packages have been found: * ECM (required version = 0.0.11) * Qt5Core (required version = 5.2.0) * KF5Archive * LibXslt , http://xmlsoft.org/XSLT Required by the KDE help system to process DocBook XML * LibXml2 , http://xmlsoft.org Required by the KDE help system to process DocBook XML * DocBookXML4 (required version = 4.5) , DocBook XML 4 , http://www.oasis-open.org/docbook/xml/4.5 Required by the KDE help system to process DocBook XML * DocBookXSL , DocBook XSL , http://docbook.sourceforge.net/release/xsl/current/ Required by the KDE help system to process DocBook XML -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: KDE4_BUILD_TESTS LIB_SUFFIX SIP_DEFAULT_SIP_DIR -- Build files have been written to: http://build.kde.org/job/kdoctools_master_qt5/ws/build == Commencing the Build Scanning dependencies of target docbookl10nhelper_automoc Scanning dependencies of target meinproc5_automoc Scanning dependencies of target KF5XsltKde_automoc [ 5%] [ 11%] [ 17%] Automatic moc for target docbookl10nhelper Automatic moc for target KF5XsltKde Automatic moc for target meinproc5 [ 17%] Built target docbookl10nhelper_automoc [ 17%] [ 17%] Built target meinproc5_automoc Built target KF5XsltKde_automoc Scanning dependencies of target docbookl10nhelper [ 29%] [ 29%] Building CXX object src/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper_automoc.cpp.o Building CXX object src/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper.cpp.o Scanning dependencies of target KF5XsltKde [ 35%] Scanning dependencies of target meinproc5 [ 41%] Building CXX object src/CMakeFiles/KF5XsltKde.dir/xslt.cpp.o [ 47%] Building CXX object src/CMakeFiles/KF5XsltKde.dir/KF5XsltKde_automoc.cpp.o [ 52%] Building CXX object src/CMakeFiles/KF5XsltKde.dir/xslt_kde.cpp.o [ 58%] [ 64%] Building CXX object src/CMakeFiles/meinproc5.dir/meinproc_common.cpp.o Building CXX object src/CMakeFiles/meinproc5.dir/xslt.cpp.o Building CXX object src/CMakeFiles/meinproc5.dir/meinproc.cpp.o [ 70%] [ 76%] Building CXX object
Review Request 116785: Unbreak bootstrapping
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116785/ --- Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- We still need to be able to load catalog files from source dir when building kdoctools itself, so generalize code from locateFileInDtdResource() instead of doing our own. Diffs - src/xslt.h 83d48b3 src/xslt.cpp 0954720 Diff: https://git.reviewboard.kde.org/r/116785/diff/ Testing --- Rebuilt kdoctools in a clean environment, as well as the rest of the frameworks. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116785: Unbreak bootstrapping
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116785/#review52892 --- Ship it! Discussed on IRC - Luigi Toscano On March 13, 2014, 2:50 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116785/ --- (Updated March 13, 2014, 2:50 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- We still need to be able to load catalog files from source dir when building kdoctools itself, so generalize code from locateFileInDtdResource() instead of doing our own. Diffs - src/xslt.h 83d48b3 src/xslt.cpp 0954720 Diff: https://git.reviewboard.kde.org/r/116785/diff/ Testing --- Rebuilt kdoctools in a clean environment, as well as the rest of the frameworks. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116785: Unbreak bootstrapping
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116785/#review52893 --- This review has been submitted with commit 4ba9dc99782de21d9fcc89910847a4a1d98889f9 by Aurélien Gâteau to branch master. - Commit Hook On March 13, 2014, 1:50 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116785/ --- (Updated March 13, 2014, 1:50 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- We still need to be able to load catalog files from source dir when building kdoctools itself, so generalize code from locateFileInDtdResource() instead of doing our own. Diffs - src/xslt.h 83d48b3 src/xslt.cpp 0954720 Diff: https://git.reviewboard.kde.org/r/116785/diff/ Testing --- Rebuilt kdoctools in a clean environment, as well as the rest of the frameworks. Thanks, Aurélien Gâteau ___ 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 : kdoctools_master_qt5 #39
See http://build.kde.org/job/kdoctools_master_qt5/39/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116785: Unbreak bootstrapping
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116785/ --- (Updated March 13, 2014, 2:09 p.m.) Status -- This change has been marked as submitted. Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- We still need to be able to load catalog files from source dir when building kdoctools itself, so generalize code from locateFileInDtdResource() instead of doing our own. Diffs - src/xslt.h 83d48b3 src/xslt.cpp 0954720 Diff: https://git.reviewboard.kde.org/r/116785/diff/ Testing --- Rebuilt kdoctools in a clean environment, as well as the rest of the frameworks. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116760: Remove kcookiescfg update scripts
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116760/ --- (Updated March 13, 2014, 2:49 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and David Faure. Repository: kio Description --- Am I right about this? Remove kcookiescfg update scripts kf5 stores configuration in different locations to kde4, so there should be nothing to update. Diffs - src/ioslaves/http/kcookiejar/CMakeLists.txt 2bb4cc232b7011d38033da10bb312a12215cb29d src/ioslaves/http/kcookiejar/kcookiescfg.pl 7fef01d5c208a00987b3594411ce06799457 src/ioslaves/http/kcookiejar/kcookiescfg.upd 745f545090875d5d24e1e6bb397af9926704350f Diff: https://git.reviewboard.kde.org/r/116760/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116760: Remove kcookiescfg update scripts
On March 12, 2014, 5:39 p.m., David Faure wrote: well I'm still hoping some sort of migration of the useful config data will happen OK, I'll leave this for now, then. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116760/#review52831 --- On March 12, 2014, 3:44 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116760/ --- (Updated March 12, 2014, 3:44 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- Am I right about this? Remove kcookiescfg update scripts kf5 stores configuration in different locations to kde4, so there should be nothing to update. Diffs - src/ioslaves/http/kcookiejar/CMakeLists.txt 2bb4cc232b7011d38033da10bb312a12215cb29d src/ioslaves/http/kcookiejar/kcookiescfg.pl 7fef01d5c208a00987b3594411ce06799457 src/ioslaves/http/kcookiejar/kcookiescfg.upd 745f545090875d5d24e1e6bb397af9926704350f Diff: https://git.reviewboard.kde.org/r/116760/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116786: Make error handling more consistent and fail earlier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116786/ --- Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This should makes it easier to interpret future failures, for example by not running xmllint if catalogs are missing. Diffs - src/meinproc.cpp 22150ab Diff: https://git.reviewboard.kde.org/r/116786/diff/ Testing --- Clean-rebuilt all frameworks which depends on kdoctools, plus kde-runtime, kde-workspace, konsole, kate. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/#review52902 --- Looks good, just a few items below: src/core/kconfigini.cpp https://git.reviewboard.kde.org/r/116689/#comment37235 Is there a reason for these extra debug statements? src/core/kcoreconfigskeleton.cpp https://git.reviewboard.kde.org/r/116689/#comment37236 Similarly, does this need to be uncommented now? src/core/kcoreconfigskeleton.cpp https://git.reviewboard.kde.org/r/116689/#comment37237 Also, can you change the documentation for KCoreConfigSkeleton to reflect this change? Specifically, for the configname parameter, can you change it something like: name of config file. If no name is given, the default from KSharedConfig::openConfig() is used - Matthew Dawson On March 10, 2014, 4:36 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 10, 2014, 4:36 a.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kconfigini.cpp df834f57fc44bbf9f4f28f1bc4eb5717e2ff1cee src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
On March 13, 2014, 7:54 p.m., Matthew Dawson wrote: src/core/kconfigini.cpp, lines 86-89 https://git.reviewboard.kde.org/r/116689/diff/1/?file=253150#file253150line86 Is there a reason for these extra debug statements? Argh, that stupid post-review script+alias always grabs local uncommitted changes while I only want to push the last commit. Let me try to fix that On March 13, 2014, 7:54 p.m., Matthew Dawson wrote: src/core/kcoreconfigskeleton.cpp, line 990 https://git.reviewboard.kde.org/r/116689/diff/1/?file=253151#file253151line990 Also, can you change the documentation for KCoreConfigSkeleton to reflect this change? Specifically, for the configname parameter, can you change it something like: name of config file. If no name is given, the default from KSharedConfig::openConfig() is used I don't understand, the documentation already says that. Do you mean mentionning DelayedParsing in the documentation? It's kind of an internal detail though. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/#review52902 --- On March 10, 2014, 8:36 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 10, 2014, 8:36 a.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kconfigini.cpp df834f57fc44bbf9f4f28f1bc4eb5717e2ff1cee src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 13, 2014, 8:06 p.m.) Review request for KDE Frameworks and Matthew Dawson. Changes --- Ah! Fixed my post-review git alias using --revision-range=HEAD~:HEAD Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs (updated) - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116786: Make error handling more consistent and fail earlier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116786/#review52907 --- src/meinproc.cpp https://git.reviewboard.kde.org/r/116786/#comment37240 Please save the value of tss before the call, otherwise it will be always empty - Luigi Toscano On March 13, 2014, 5:39 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116786/ --- (Updated March 13, 2014, 5:39 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This should makes it easier to interpret future failures, for example by not running xmllint if catalogs are missing. Diffs - src/meinproc.cpp 22150ab Diff: https://git.reviewboard.kde.org/r/116786/diff/ Testing --- Clean-rebuilt all frameworks which depends on kdoctools, plus kde-runtime, kde-workspace, konsole, kate. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
On March 13, 2014, 3:54 p.m., Matthew Dawson wrote: src/core/kcoreconfigskeleton.cpp, line 990 https://git.reviewboard.kde.org/r/116689/diff/1/?file=253151#file253151line990 Also, can you change the documentation for KCoreConfigSkeleton to reflect this change? Specifically, for the configname parameter, can you change it something like: name of config file. If no name is given, the default from KSharedConfig::openConfig() is used David Faure wrote: I don't understand, the documentation already says that. Do you mean mentionning DelayedParsing in the documentation? It's kind of an internal detail though. It does basically say that. The current text is: name of config file. If no name is given, the default config file as returned by KSharedConfig::openConfig() is used I just worry the wording may have people assume we don't change any other parameters, though it could just be me looking to closely at this issue. If you think the current version is more clear, then the patch can go in as is. If you have a third option, I'm happy for to hear it, otherwise I'd prefer the updated version. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/#review52902 --- On March 13, 2014, 4:06 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 13, 2014, 4:06 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
On March 13, 2014, 7:54 p.m., Matthew Dawson wrote: src/core/kcoreconfigskeleton.cpp, line 990 https://git.reviewboard.kde.org/r/116689/diff/1/?file=253151#file253151line990 Also, can you change the documentation for KCoreConfigSkeleton to reflect this change? Specifically, for the configname parameter, can you change it something like: name of config file. If no name is given, the default from KSharedConfig::openConfig() is used David Faure wrote: I don't understand, the documentation already says that. Do you mean mentionning DelayedParsing in the documentation? It's kind of an internal detail though. Matthew Dawson wrote: It does basically say that. The current text is: name of config file. If no name is given, the default config file as returned by KSharedConfig::openConfig() is used I just worry the wording may have people assume we don't change any other parameters, though it could just be me looking to closely at this issue. If you think the current version is more clear, then the patch can go in as is. If you have a third option, I'm happy for to hear it, otherwise I'd prefer the updated version. I cannot see a meaningful difference between the default config file as returned by openConfig() and the default from openConfig() ? I kind of doubt anyone reading the docs would really see a difference there. In fact the first one is arguably more correct, since we use the default config file but not with the default flags... - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/#review52902 --- On March 13, 2014, 8:06 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 13, 2014, 8:06 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116747: Clean up KCompletionBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/ --- (Updated March 13, 2014, 10:13 p.m.) Review request for KDE Frameworks. Changes --- Restore and rephrase comment in kcompletionbox.cpp, following suggestion of Alex Merry. Repository: kcompletion Description --- Clean up KCompletionBox -canceled() - cancelled (private method) -Deprecate sizeAndPosition() -- resizeAndReposition() -Remove old comments and commented-out code -Move some slots to be normal methods, since they don't seem to be able to work as slots. Diffs (updated) - src/kcompletionbox.h 09b7527 src/kcompletionbox.cpp 92e87b3 Diff: https://git.reviewboard.kde.org/r/116747/diff/ Testing --- It builds and tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/#review52913 --- Ship it! Ship It! - Matthew Dawson On March 13, 2014, 4:06 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 13, 2014, 4:06 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review52915 --- You'll need a drawable, clients will require XInitThreads if that is accessed from a different than the GUI thread, but it might be possible to use an internal Window and move the QObject to the GUI thread on construction. src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37245 QWidget::winId() src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37246 QWidget::winId() - Thomas Lübking On March 13, 2014, 6:44 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 13, 2014, 6:44 p.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116792: Fix deprecation warning in KComboBox and fix all KDE_NO_DEPRECATED
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116792/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Fix deprecation warning in KComboBox and fix all KDE_NO_DEPRECATED There are other warnings related to the deprecated KComboBox::setUrlDropsEnabled, which calls KLineEdit::setUrlDropsEnabled (also deprecated). I tried to solve it by copying the KLineEdit::setUrlDropsEnabled contents into KComboBox::setUrlDropsEnabled, but it contains private variables which it cannot see. Any hint?? Diffs - autotests/klineedit_unittest.cpp b84e126 src/kcombobox.h 32dc3e9 src/kcombobox.cpp 7195b3e src/kcompletion.h 387a05e src/klineedit.h c7c46b5 src/klineedit.cpp ae15093 Diff: https://git.reviewboard.kde.org/r/116792/diff/ Testing --- It builds and tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
ECM uninstall target
alohas, I just ported phonon/five to ECM and noticed that apparently ECM does not have an include or something to introduce an uninstall target. Are there plans to introduce such a thing or am I simply blind and not seeing the already existing include? HS
Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/#review52887 --- Looks good, apart from method name and coding style (spaces in all sorts of wrong places, for historic reasons - OK to leave as it here, but run astyle-kdelibs or clean by hand after patching the kio framework, which has been made consistent style-wise). kioslave/ftp/ftp.cpp https://git.reviewboard.kde.org/r/116783/#comment37232 It's a bit confusing to have two methods called ftpSize. Maybe call this one ftpSizeCmd() or something? (check existing method names for consistency) - David Faure On March 13, 2014, 12:33 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 12:33 p.m.) Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Review Request 116784: Fix incorrect use of KDateTime.toTime_t in kio_http
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/ --- Review request for kdelibs, Andreas Hartmetz and David Faure. Repository: kdelibs Description --- The attached patch does the following: - It corrects a mistake in assumption that KDateTime.toTime_t() will return -1 for invalidate dates. It does not. The result is an overflow which is interpreted in kio_http as a timestamp in the distant future which obviously is wrong. See https://bugs.kde.org/show_bug.cgi?id=331774 for example. This assumption also affects the timestamp variables used for cache management. - It converts cache management timestamp variables to 64 bits so they can accomodates dates beyond Feb 7, 2106. Diffs - kioslave/http/http.h dd85622 kioslave/http/http.cpp e4f1eba Diff: https://git.reviewboard.kde.org/r/116784/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
On March 13, 2014, 12:40 p.m., David Faure wrote: kioslave/ftp/ftp.cpp, line 2260 https://git.reviewboard.kde.org/r/116783/diff/2/?file=253641#file253641line2260 It's a bit confusing to have two methods called ftpSize. Maybe call this one ftpSizeCmd() or something? (check existing method names for consistency) Ok. I will rename it ftpSendSizeCmd for consistency and adjust the spaces to 2 for this branches and correct it properly for the frameworks branch. - Dawit --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/#review52887 --- On March 13, 2014, 12:33 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 12:33 p.m.) Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 12:58 p.m.) Review request for kdelibs and David Faure. Changes --- Updated patch. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs (updated) - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/#review52891 --- kioslave/ftp/ftp.cpp https://git.reviewboard.kde.org/r/116783/#comment37234 Misunderstanding, I wasn't talking about indentation (which indeed ends up being 4 spaces everywhere in frameworks). The issue is more: no space after this if, one space too many after psz on the previous line, too many spaces inside the parenthesis on the line Ftp::ftpSize( ... ), etc. My suggestion was to just do this automatically in frameworks using a tool, otherwise you have to do it correctly by hand :-) - David Faure On March 13, 2014, 12:58 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 12:58 p.m.) Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116784: Fix incorrect use of KDateTime.toTime_t in kio_http
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/#review52897 --- The handling of return values from KDateTime::toTime_t() in the existing kio_http code is not correct, because the return value's type is implicitly cast to other types before being checked. For example, in one place it is cast to qint64, which will result in a value of 0x instead of 0x (= -1). This type of error will mask the fact that the error value is being returned. Instead of changing the calling code to detect invalid dates using other methods, it should be fixed to properly cast the uint value returned from KDateTime::toTime_t(). For types other than int, it needs to specifically check for uint(-1) and set the cast value to -1 in that case. For example: uint t = KDateTime::toTime_t(...); // Set the qint64 to be -1 if an error occurred: qint64 result = (t == uint(-1)) ? -1 : t; Note: KDateTime::toTime_t() is *supposed* to return uint(-1) to indicate an error. If it doesn't always do this, *it* should be fixed instead of changing code elsewhere, since kio_http is unlikely to be the only module that will have trouble if that is happening. - David Jarvie On March 13, 2014, 12:49 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/ --- (Updated March 13, 2014, 12:49 p.m.) Review request for kdelibs, Andreas Hartmetz and David Faure. Repository: kdelibs Description --- The attached patch does the following: - It corrects a mistake in assumption that KDateTime.toTime_t() will return -1 for invalidate dates. It does not. The result is an overflow which is interpreted in kio_http as a timestamp in the distant future which obviously is wrong. See https://bugs.kde.org/show_bug.cgi?id=331774 for example. This assumption also affects the timestamp variables used for cache management. - It converts cache management timestamp variables to 64 bits so they can accomodates dates beyond Feb 7, 2106. Diffs - kioslave/http/http.h dd85622 kioslave/http/http.cpp e4f1eba Diff: https://git.reviewboard.kde.org/r/116784/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 109675: Make sure that the KDE prefix comes first in XDG_DATA_DIRS
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/109675/#review52898 --- introduced regression'y behavior, see https://bugs.kde.org/show_bug.cgi?id=332107 - Rex Dieter On March 25, 2013, 7:14 p.m., Andreas Hartmetz wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/109675/ --- (Updated March 25, 2013, 7:14 p.m.) Review request for kdelibs and Vishesh Handa. Repository: kde-workspace Description --- Planned commit message: Make sure that the KDE prefix comes first in XDG_DATA_DIRS. I tracked down a Nepomuk problem to this. Nepomuk file indexing didn't work because the ontologies were too old. Nepomuk loaded ontologies from /usr/share instead of my KDE prefix /opt/kde4/share, because /opt/kde4 was the very last entry in the respective search list in KStandardDirs. The first entries in that search list all came from XDG_DATA_DIRS, which in my case (Kubuntu) is set by the X session initialization scripts. That is before startkde runs, so startkde never touched XDG_DATA_DIRS. But it should, and now it does. Diffs - startkde.cmake 8361fe0 Diff: https://git.reviewboard.kde.org/r/109675/diff/ Testing --- Thanks, Andreas Hartmetz
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 10:15 p.m.) Review request for kdelibs and David Faure. Changes --- updated patch Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs (updated) - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
On March 13, 2014, 1:10 p.m., David Faure wrote: kioslave/ftp/ftp.cpp, line 2302 https://git.reviewboard.kde.org/r/116783/diff/3/?file=253646#file253646line2302 Misunderstanding, I wasn't talking about indentation (which indeed ends up being 4 spaces everywhere in frameworks). The issue is more: no space after this if, one space too many after psz on the previous line, too many spaces inside the parenthesis on the line Ftp::ftpSize( ... ), etc. My suggestion was to just do this automatically in frameworks using a tool, otherwise you have to do it correctly by hand :-) I will use the tool you mentioned for frameworks, but for this one I have tried to fix all the glaring ones you mentioned - Dawit --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/#review52891 --- On March 13, 2014, 10:15 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 10:15 p.m.) Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/#review52916 --- Ship it! Ship It! - David Faure On March 13, 2014, 10:15 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 10:15 p.m.) Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116784: Fix incorrect use of KDateTime.toTime_t in kio_http
On March 13, 2014, 5:30 p.m., David Jarvie wrote: The handling of return values from KDateTime::toTime_t() in the existing kio_http code is not correct, because the return value's type is implicitly cast to other types before being checked. For example, in one place it is cast to qint64, which will result in a value of 0x instead of 0x (= -1). This type of error will mask the fact that the error value is being returned. Instead of changing the calling code to detect invalid dates using other methods, it should be fixed to properly cast the uint value returned from KDateTime::toTime_t(). For types other than int, it needs to specifically check for uint(-1) and set the cast value to -1 in that case. For example: uint t = KDateTime::toTime_t(...); // Set the qint64 to be -1 if an error occurred: qint64 result = (t == uint(-1)) ? -1 : t; Note: KDateTime::toTime_t() is *supposed* to return uint(-1) to indicate an error. If it doesn't always do this, *it* should be fixed instead of changing code elsewhere, since kio_http is unlikely to be the only module that will have trouble if that is happening. Perhaps it was not clear from the description, but I am not implying nor have I implied there to be a bug in KDateTime. As I have clearly stated the problem is with the assumption the code in kio_http makes about what KDateTime::toTime_t returns for an invalid date. No matter how you see it the toTime_t() function can not and does not return a literal -1, which is exactly what the code in kio_http assumes! Of course that is clearly wrong. Anyhow, this patch is specifically intended to fix that issue and nothing else. - Dawit --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/#review52897 --- On March 13, 2014, 12:49 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/ --- (Updated March 13, 2014, 12:49 p.m.) Review request for kdelibs, Andreas Hartmetz and David Faure. Repository: kdelibs Description --- The attached patch does the following: - It corrects a mistake in assumption that KDateTime.toTime_t() will return -1 for invalidate dates. It does not. The result is an overflow which is interpreted in kio_http as a timestamp in the distant future which obviously is wrong. See https://bugs.kde.org/show_bug.cgi?id=331774 for example. This assumption also affects the timestamp variables used for cache management. - It converts cache management timestamp variables to 64 bits so they can accomodates dates beyond Feb 7, 2106. Diffs - kioslave/http/http.h dd85622 kioslave/http/http.cpp e4f1eba Diff: https://git.reviewboard.kde.org/r/116784/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 11:30 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: Review Request 116783: Change ftpFileExists to use relative paths for SIZE requests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/#review52918 --- This review has been submitted with commit 0d8913d2b544c16043262ac5380fa899b711d59b by Dawit Alemayehu to branch KDE/4.12. - Commit Hook On March 13, 2014, 10:15 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116783/ --- (Updated March 13, 2014, 10:15 p.m.) Review request for kdelibs and David Faure. Repository: kdelibs Description --- I completely missed ftpFileExists issued a SIZE command to determine the existence of a file when addressing bug# 326292. See https://git.reviewboard.kde.org/r/116524/ review request. The attached patch addresses that oversight to insure renaming files work properly on the android ftp server listed in the bug report. Diffs - kioslave/ftp/ftp.h cbcd096 kioslave/ftp/ftp.cpp b9d90e6 Diff: https://git.reviewboard.kde.org/r/116783/diff/ Testing --- Rerun all the tests run for 116524. Thanks, Dawit Alemayehu
Re: GSoC Ideas involving Baloo
On Thursday, March 13, 2014 10:57:35 AM Denis Steckelmacher wrote: Hi, Hey Dennis Several days ago, I told you that I would be very happy to find a GSoC project useful to Baloo and its users. I asked on my blog for ideas and I've got very interesting answers. Somebody told me that a multimedia tagging library would be very useful for many people. If I understand correctly the idea, such a library would provide applications an easy way to tag multimedia files. Such a library made me think of several features that could be interesting to add to Baloo: * Support for arbitrary attributes in the file search store (so that we don't need to add explicit support for the hundreds of properties that JPEG and MP3 files can have), if you think that it's a good idea I'm not sure I understand, could you please elaborate. * File extractors for taglib, jpeg, video files, etc, if they don't already exist (by the way, where do the file extractors live in the Baloo source code?) They exist. There are in a separate repository called kfilemetadata * File injectors: this idea has been proposed by many people (and also on the Baloo wiki I think) and consists of writing back Baloo metadata into files that support them. For instance, audio files support tags, authors, etc. Office files generally support authors and comments, HTML files support tags, etc. Yes, this is something we might want. It would also mean re-purposing kfilemetadata to allow extractors and writeback. * Remote file extractors: if the user asks for it, such extractors could be used to query IMDB for tags and attributes. This should not be automatic as downloading web pages takes time and bandwidth, but having a button in FileMetadataWidget to perform this task may be useful to many people. Nepomuk had a concept of indexing level, does a similar concept exist in Baloo? Having online content is always useful, but in the right settings. It may not be very useful in Dolphin which is after all a file manager, but it would be very very useful in a media application. In that case the media player would be responsible for deciding when to fetch the online data. And then, we don't really need to store that information in the same index as the current files. Unless this needs to be part of the global search. This is probably best discussed with the multimedia guys, Plasma Media Center, and Jorg who did the Nepomuk web-extractor. Do you think that these points could be subject to a GSoC project? Would they be useful to Baloo? Such a project could be titled Multimedia Support in Baloo, its goal being to use Baloo for multimedia information as extensively as it is currently used for PIM information. Denis Steckelmacher -- Vishesh Handa Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
[GSoC 2014] Looking for a mentor
Hello folks! I want to participate in a Google Summer of Code 2014, working for KDE organisation. I want to propose my own project, which is a screencast recording app for KDE. I'd be very glad if someone (I think kdemultimedia or kdegraphics participants could find it useful) can review my proposal and accept to be my mentor. I'm sending a draft of my application idea for now - please tell me if you want a document in a GSoC format if you're interested. I attach my description written so far. Thank you in advance! Marcin Grzywaczewski Institute of Computer Science on University of Wrocław KoolKast - easy screencasting tool for KDE Features: * Recording user's screen: * All screens * Certain screen * Window * Region of screen * Recording audio * Microphone * System sounds * Encoding created screencast to WebM * Timers * Integration with KDE notifier And, when we'll have some time: * (OPTIONAL) Modification of created file's metadata * (OPTIONAL) Very simple video manipulation * deleting parts of the video * inserting static frames [like company logo, or chapter description text] Motivation: Screencasting gains more and more popularity as a tool for sharing knowledge - many software houses which aiming for a remote work start to use it widely within their knowledge bases. It's also a great tool for an end-user - rather than creating an article about process you want to share, you can record the process and explain it in plain words. In Ruby on Rails community we can talk about 'screencasting culture' already - services like RailsCasts, excellent screencasts made by Gary Bernhardt (Destroy All Software series) and many more. Unfortunately, Linux and Open Source systems lack the proper tools for creating screencasts - every one of them is too complicated, have weird issues (like Kazam - a tool which I'm using right no. It lacks, for example, encoding status and when something goes wrong it doesn't even inform you such case happened) or is not suitable for easy sharing (lacking WebM standard encoding, which is a web standard). I think providing an easy software for creating screencast within KDE project can greatly increase value of our DE. Many professionals these days are using Apple Mac just because such tasks like screencasting just works - you press one button and you are done. When we provide such tool as the part of KDE, we can convince those people, who would like to use Linux, but they're angry now because there is no good tooling for this kind of easy tasks. As an user of Linux and KDE (love it since version 3) and programmer in a software house which has grown 'screencasting culture', I would be glad to provide such solution to our Desktop Environment. Scope: During GSoC I'd like to focus on very narrow scope of providing critical features in a proper way. I'm open for suggestions - if you want to mentor my project, I'd be glad to discuss about my proposed scope and change it accordingly. Features desciption (with insight about implementation and architecture): * RECORDING USER'S SCREEN Yeah, it's the most important part of the screencasting app (with audio recording, of course). During the work on this feature I'd like to create an architecture for 'exchangeable' adapters for recording screen technique (expose an interface for future development of new adapters and provide a way to 'register' it within KoolKast. This way you can have many techniques of recording) and ability of defining the very basic settings of this - like resolution, quality and framerate. I'd like to create one basic adapter for recording screencasts, mostly QScreenshot based - but I'm open for suggestions. My 'must-be' part of this feature is to be able to record all screens, certain screen and a window. When I'll have time for it I'll also try to implement region recording. We can also re-use or take inspiration from recordmydesktop if license allows us to do so. Challenges: It can be tricky to synchronize audio with video when there are performance problems - I'd like to take a closer look on it. * RECORDING AUDIO When it comes to recording audio, my goal is to provide a good support for a microphone - recording system sounds is less major than a mic, just because that's why screencast are created for - to provide a vision of the process (by an example) and to explain it in the same time using speech. I'm not sure about technical implementation right now - I think we have an abstraction in Qt called QAudioRecorder which we can use in this case. Encoding it to a proper format will handled by the encoder. I'd like to provide very basic settings within UI - selecting audio input, setting volume and quality of the recorded audio. Challenges: There can be a requirement to provide a service to interact with encoder and an audio recording module. * ENCODING CREATED SCREENCAST TO WEBM WebM becomes more and more popular because it's natively
Re: GSoC Ideas involving Baloo
On 03/13/2014 03:52 PM, Vishesh Handa wrote: * Support for arbitrary attributes in the file search store (so that we don't need to add explicit support for the hundreds of properties that JPEG and MP3 files can have), if you think that it's a good idea I'm not sure I understand, could you please elaborate. I have explored the code of the file indexers, and there is a file named properties.h (it declares the valid properties that can be used when extracting files). This list is quite extensive and seems to alleviate my problem: I thought that only the 5-6 properties listed at the beginning of the file search store source code (in Baloo Core) were available. By the way, PropertyInfo is also very interesting and it may be interesting to use it in the query parser (so that the user can enter artist is Foo and queries like that). This justifies putting the query parser in a separate library to avoid a cyclic dependency between Baloo Core and kfilemetadata. * Remote file extractors: if the user asks for it, such extractors could be used to query IMDB for tags and attributes. This should not be automatic as downloading web pages takes time and bandwidth, but having a button in FileMetadataWidget to perform this task may be useful to many people. Nepomuk had a concept of indexing level, does a similar concept exist in Baloo? Having online content is always useful, but in the right settings. It may not be very useful in Dolphin which is after all a file manager, but it would be very very useful in a media application. In that case the media player would be responsible for deciding when to fetch the online data. And then, we don't really need to store that information in the same index as the current files. Unless this needs to be part of the global search. This is probably best discussed with the multimedia guys, Plasma Media Center, and Jorg who did the Nepomuk web-extractor. Okay, I will talk to them. Storing this kind of meta-data directly in the Baloo database could be useful because it would allow a generic application (like a Baloo browser or search engine, or a file manager) to find documents and media content based on any search. For instance, an application like Plasma Media Center (or even Plasma Active) could display files sorted by album, author, composer, series, origin, type, etc. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Re: [GSoC 2014] Looking for a mentor
Hello Kevin, Much appreciated that you replied so fast! The main point of my app is that it should be easy to use for an end-user - as I pointed many times in this document we lack the good and easy to use tools compared, for example, to MacOS. I think using recordmydesktop as a one of video recorders within proposed architecture can be a way to go. Recordmydesktop is quite mature app and many things can be easily ported or used entirely within KoolKast (it's an experimental name ;))! It's a good point to not reinvent a wheel again. But Recordmydesktop has some issues: 1. It's a console application - it's fine, great and UNIX-way, but I'm not sure it's a way to go for my target. 2. It's not integrated into KDE - I want to use good notifications and OSD. It's a minor from the developer's POV, but major for the user to get a good notifications. I want to create an easy to use, reliable tool for screencasting that is integrated with KDE. That's my point - for me, recordmydesktop is not standing for this definition. I had the discussion on #kde-soc @ Freenode about this application. It seems that we can continue work on Recorditnow or some other desktop recording tools to transform it into a reliable screencasting tool for KDE. Such way my proposal can be changed to develop an existing app to perform such task. Please tell me what you think about it! Thank you in advance, Marcin Grzywaczewski Institute of Computer Science on University of Wrocław Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Re: [GSoC 2014] Looking for a mentor
ffmpeg's x11 screen grab does a good job of screen casting as well. this is what kdenlive now uses. On Mar 13, 2014 10:24 PM, Marcin Grzywaczewski killa...@gmail.com wrote: Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [GSoC 2014] Looking for a mentor
Hi Marcin, On Thursday, 2014-03-13, 17:53:31, Marcin Grzywaczewski wrote: But Recordmydesktop has some issues: 1. It's a console application - it's fine, great and UNIX-way, but I'm not sure it's a way to go for my target. 2. It's not integrated into KDE - I want to use good notifications and OSD. It's a minor from the developer's POV, but major for the user to get a good notifications. There was a KDE frontend for it once, called krecordmydesktop, there is one for GTK if my package repository search is still valid. Anyway, a different approach might yield better results, just wanted to be sure you've had a look at the available options. One other thing that came to my mind was whether that should not be part of the compositor somehow. It has the content for most (all?) windows already and knows where each window is, etc. I guess it is also the only process which can do that on Wayland. I found this on a quick googling: http://sathyasays.com/2009/03/06/using-kwin-as-a-desktop-video-recording-and-screencast-tool/ Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Re: [GSoC 2014] Looking for a mentor
Fantastic idea! If there are even basic prerequisities to build it into KWin, I'd like to develop it with pleasure. My goal is to *fix* pain with screencasting on Linux - and means are not that urgent - it can be a plugin to KWin, another program, developing an existing app etc. Do you are interested in developing it inside KWin, really? I'd be happy to cooperate on such task! Thank you for interesting read, Kevin! Marcin Grzywaczewski Institute of Computer Science on University of Wroclaw Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [GSoC 2014] Looking for a mentor
On Thursday, 2014-03-13, 20:00:14, Marcin Grzywaczewski wrote: Fantastic idea! If there are even basic prerequisities to build it into KWin, I'd like to develop it with pleasure. My goal is to *fix* pain with screencasting on Linux - and means are not that urgent - it can be a plugin to KWin, another program, developing an existing app etc. Do you are interested in developing it inside KWin, really? I'd be happy to cooperate on such task! I have actually no clue :) I just remembered reading about that KWin plugin and remember thinking that it was pretty smart to get the screen image at the source so to speak. It might very well be an extremly stupid thing to do for what I know, lets CC the KWin developers ;-) @KWin people: we are discussing this [1] in that [2] context Thank you for interesting read, Kevin! You're welcome! Another thing I came across (again) is this blog entry: http://alicious.com/recap-kde4-video-screen-capture/ Seems KDEnlive is also using recordmydesktop under the hood for screencapture. But that was in 2009, so better options might exist today. Cheers, Kevin [1] http://sathyasays.com/2009/03/06/using-kwin-as-a-desktop-video-recording-and-screencast-tool/ [2] http://lists.kde.org/?t=13947269235r=1w=2n=6 -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
nepomuk/baloo
Further to a question on kdepim - should nepomuk_file_indexer be running as well as baloo_file? Or is nepomuk_file_indexer obsolete? -- Lindsay signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On 13/03/2014, at 12:46 AM, Kevin Krammer wrote: On Monday, 2014-03-10, 17:06:53, Ian Wadham wrote: P.S. I see from your signature you are a developer mentor, Kevin. Would you be able to mentor me while I try to get a handle on some of the problems with running KDE apps in an Apple environment? Like my first problem will be why plugins sometimes work and sometimes not, in KDE on Apple OS X. Not sure I can really help you since I have no clue but I can sure try. Well, thank you very much for that, Kevin. May I write to you privately to get started? I think I will just have a list of questions from time to time, as I get stuck when tracking down problems, and I hope I will be up to speed within a couple of months. Cheers, Ian W. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On 13/03/2014, at 12:46 AM, Kevin Krammer wrote: On Monday, 2014-03-10, 17:06:53, Ian Wadham wrote: On 09/03/2014, at 8:23 PM, Kevin Krammer wrote: Hi Ian, On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote: Hi Kevin and Frank, I think they probably are non-overlapping sets. There *is* a KDE Mac mailing list, but I receive only a few posts per year from it, as compared with several a day from Macports. Ah, interesting. This makes it very different from all other platforms (various Linux distributions, BSD, Windows, mobile platforms), where some of the packagers are also KDE developers. Macports grew out of something Apple did in the early days, mainly directed at getting any kind of free open-source software onto Apple Mac. There are also Fink and Homebrew doing similar jobs. A lot of the emphasis is on GNU utilities and languages such as Perl, TCL and Python, plus some Science packages and Fortran, used by real scientists, free database packages (mysql, mariadb, sqlite, etc.). The Macports have fantastic Unix/BSD and sysadmin skills, but not much knowledge of KDE. The KDE porting team does a good job and are currently at KDE 4.12.2, but they make not much attempt to adapt or convert KDE to run smoothly in the Apple OS X environment. One guy goes a bit deeper, with KMyMoney4, and is in touch with the developers, I think. I help him too, when I can. Both of us rely on KMM4 to run our finances … ;-) I see, that makes it indeed very different from packaging efforts on any other platform. Well yes. I think the KDE community is very lucky to have such helpers, but I guess you cannot count on them being present on every platform … That might of course be true, but also a bit uncommon. Packaging efforts for all other platforms is at least to some extend handled by people who are either users of the packaged software or KDE developers using the respective platform. Part of the problem may be that, until recently, it has been difficult for a KDE developer to just buy a MacBook Pro and set up a dual-boot or virtualised Linux system on it. But now it is quite easy … :-) I aim to have a go, once I have Palapeli for KDE 4.13 put to bed. The main part of the problem, i.e. Apple at least officially requring special hardware, still remains. I am not sure it is feasible to assume anyone would buy a second computer just to satisfy some hardware vendor's lock-in phantasies. I think your prejudices are showing, Kevin … :-) That might very well be. I actually know people who have a so called Hackintosh, but I've never figured out how they actually get OSX. OS X is bundled in and stored in the hardware when you buy it and has a well thought out mix of default settings. It remains for you to set up user and admin accounts, which the Apple Shop help you to do. For updating (when you feel like it, no pestering) you run AppleMenu- Software Update. It tells you what new items are available and what the significance of each new version is, and then you can choose which ones to install. Major upgrades, such as Lion 10.7 to Mavericks 4.9 are offered by email, with links to websites describing the features. You can obtain an upgrade from a website when and if you want it. It is not unlike working with OpenSuSE. My information, and it seems to be confirmed by other people in this thread, was that Apple did not sell OSX licenses separately, only bundled with their hardware. Another piece of information that might be outdated is that Apple's license terms, at least in some jurisdictions, do not allow to run OSX in a virtualized environment. Which made OSX almost impossible to use in continuous integration and removes the only viable option for quick test build and test runs for the average developer. Again my impression from other responses is that this is still true, but these responders might like me also not be up to date on the whole situation. Actually Apple Mac hardware is bog-standard Intel underneath and OS X is BSD UNIX underneath. Right, but that is the buys special hardware situation I was referring to before. Do you know if the Mac packaging group is just building the software or if they also run the automated tests? I don't know for sure, but I think they just build, sometimes patching to overcome incompatibility problems and build failures. I see. My assumption until this thread was that OSX as a target platform was handled similar to how all other were handled, i.e. a group of people with deeper understanding of the platform's peculiarities would build the software, fix eventual problems and upstream those fixes. Doing the latter through persons within the group who are KDE developers. My updated understanding is that the group packaging KDE software for OSX does not have any members who are KDE developers, I am not certain of that, but it is probably so. right, seems
Re: Running KDE apps on Apple OS X
On 12/03/2014, at 8:31 AM, Daniel Kreuter wrote: Am 11.03.2014 um 04:15 schrieb Ian Wadham iandw...@gmail.com: Now it works in the Macports installed version, but not in my development environment, which has several environment variables for $KDEHOME, etc. Is there perhaps a variable or path that I need to set to help find plugins? There is a variable for plugins: QT_PLUGIN_PATH, maybe this helps you? Thanks, Daniel. No, I have had that path set for quite a while. I tried adding the directory above what was set, which is where my plugin code (*.so's) actually gets installed, but no change. It looks as though KServiceTypeTrader finds the slicer OK, but then Palapeli and KService cannot load it. I will investigate further … Cheers, Ian W. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: nepomuk/baloo
On Friday 14 March 2014 07:13:16 Lindsay Mathieson wrote: Further to a question on kdepim - should nepomuk_file_indexer be running as well as baloo_file? Or is nepomuk_file_indexer obsolete? The Nepomuk indexer is obsolete if you are using Baloo, which is intended to replace Nepomuk. There is also a Baloo / Akonadi indexer agent, which you might not see running because it's so fast :) The file_indexer processes are both only for actual files AFAIK, not Akonadi resources. The Akonadi indexers are called indexing agents and have agent somewhere in their names. There is or used to be (a recent commit should have fixed it) a bug where even if your self-compiled KDE does not include Nepomuk, something starts the Nepomuk / Akonadi agent that usually comes with your distro packaging of KDE. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: nepomuk/baloo
I thought so, thanks Andreas. On 14 March 2014 11:34, Andreas Hartmetz ahartm...@gmail.com wrote: On Friday 14 March 2014 07:13:16 Lindsay Mathieson wrote: Further to a question on kdepim - should nepomuk_file_indexer be running as well as baloo_file? Or is nepomuk_file_indexer obsolete? The Nepomuk indexer is obsolete if you are using Baloo, which is intended to replace Nepomuk. There is also a Baloo / Akonadi indexer agent, which you might not see running because it's so fast :) The file_indexer processes are both only for actual files AFAIK, not Akonadi resources. The Akonadi indexers are called indexing agents and have agent somewhere in their names. There is or used to be (a recent commit should have fixed it) a bug where even if your self-compiled KDE does not include Nepomuk, something starts the Nepomuk / Akonadi agent that usually comes with your distro packaging of KDE. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Lindsay Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
