[Powerdevil] [Bug 345618] Powerdevil crash from idle desktop.
https://bugs.kde.org/show_bug.cgi?id=345618 --- Comment #2 from Matthew Dawson matt...@mjdsystems.ca --- As an additional note, this happened after my laptop had been on and idle for a while. It wasn't just after startup here. Seems like it can happen anytime, at least on KF5. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Nov. 2, 2014, 8:18 p.m.) Status -- This change has been marked as submitted. Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
On Aug. 3, 2014, 1:05 p.m., Luigi Toscano wrote: CMakeLists.txt, line 92 https://git.reviewboard.kde.org/r/119589/diff/1/?file=295158#file295158line92 Just to be sure: is khelpcenter/kf5 meant to replace khelpcenter/kdelibs4, right? (no coinstallability) As far as I know, this is true. Both versions use khelpcenter as the executable name, and kdelibs4 handbooks seem to work fine under khelpcenter/kf5. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/#review63706 --- On Aug. 3, 2014, 12:59 p.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Aug. 3, 2014, 12:59 p.m.) Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118512: Turn KFileMetaData into a Framework.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/ --- (Updated June 16, 2014, 5:44 p.m.) Status -- This change has been discarded. Review request for Plasma, Jonathan Riddell and Vishesh Handa. Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334 http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334 Repository: kfilemetadata Description --- Turn KFileMetaData into a Framework. Diffs - src/typeinfo.h 2675cbbd5751de9a7ac77cf9fdda4cb6d0a7806e src/propertyinfo.h bb54f58c750eff8c39685861a5346c025265949b src/extractors/CMakeLists.txt 0099c0878315a07f4d7b1369dc1471a8401f10a7 src/extractorpluginmanager.h d4a871e7d5952edb48c5836769741d7cf20bd29f src/extractorplugin.h 218ef207982e31f0142983d75b4846cd0f45f02a src/extractionresult.h 76dfe590aaf1f1fda265a4835fa1bcdbc81ba58a src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c autotests/CMakeLists.txt c657a7002d1d0644d6de4438a193bb63657b7ec0 KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 KF5FileMetaDataConfig.cmake.in PRE-CREATION CMakeLists.txt 5a9eefa89b2fc7e6202347daf105baa867328ffc Diff: https://git.reviewboard.kde.org/r/118512/diff/ Testing --- Tested compiling Baloo against a system install with this patch applied. Baloo sucessfully linked against the KF5 version and all Baloo tests ran to completion. All KFileMetaData unit tests passed too ;) Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118512: Turn KFileMetaData into a Framework.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/ --- (Updated June 14, 2014, 6:20 p.m.) Review request for Plasma, Jonathan Riddell and Vishesh Handa. Changes --- Replace the renaming effort with the reworking of KFileMetaData into a framework. Patch for Baloo will follow, and I'll chase down any other failures as I find them/they are pointed out. Summary (updated) - Turn KFileMetaData into a Framework. Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334 http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334 Repository: kfilemetadata Description (updated) --- Turn KFileMetaData into a Framework. Diffs (updated) - CMakeLists.txt 5a9eefa89b2fc7e6202347daf105baa867328ffc KF5FileMetaDataConfig.cmake.in PRE-CREATION KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 autotests/CMakeLists.txt c657a7002d1d0644d6de4438a193bb63657b7ec0 src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c src/extractionresult.h 76dfe590aaf1f1fda265a4835fa1bcdbc81ba58a src/extractorplugin.h 218ef207982e31f0142983d75b4846cd0f45f02a src/extractorpluginmanager.h d4a871e7d5952edb48c5836769741d7cf20bd29f src/extractors/CMakeLists.txt 0099c0878315a07f4d7b1369dc1471a8401f10a7 src/propertyinfo.h bb54f58c750eff8c39685861a5346c025265949b src/typeinfo.h 2675cbbd5751de9a7ac77cf9fdda4cb6d0a7806e Diff: https://git.reviewboard.kde.org/r/118512/diff/ Testing --- Tested compiling Baloo against a system install with this patch applied. Baloo sucessfully linked against the KF5 version and all Baloo tests ran to completion. All KFileMetaData unit tests passed too ;) Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118512: Turn KFileMetaData into a Framework.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/ --- (Updated June 14, 2014, 6:40 p.m.) Review request for Plasma, Jonathan Riddell and Vishesh Handa. Changes --- Further testing showed that the include directory was incorrectly referenced in a few places. Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334 http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334 Repository: kfilemetadata Description --- Turn KFileMetaData into a Framework. Diffs (updated) - src/typeinfo.h 2675cbbd5751de9a7ac77cf9fdda4cb6d0a7806e src/propertyinfo.h bb54f58c750eff8c39685861a5346c025265949b src/extractors/CMakeLists.txt 0099c0878315a07f4d7b1369dc1471a8401f10a7 src/extractorpluginmanager.h d4a871e7d5952edb48c5836769741d7cf20bd29f src/extractorplugin.h 218ef207982e31f0142983d75b4846cd0f45f02a src/extractionresult.h 76dfe590aaf1f1fda265a4835fa1bcdbc81ba58a src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c autotests/CMakeLists.txt c657a7002d1d0644d6de4438a193bb63657b7ec0 KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 KF5FileMetaDataConfig.cmake.in PRE-CREATION CMakeLists.txt 5a9eefa89b2fc7e6202347daf105baa867328ffc Diff: https://git.reviewboard.kde.org/r/118512/diff/ Testing --- Tested compiling Baloo against a system install with this patch applied. Baloo sucessfully linked against the KF5 version and all Baloo tests ran to completion. All KFileMetaData unit tests passed too ;) Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118512: RFC: Rename CMake configuration files to KFileMetaData5*
On June 11, 2014, 7 a.m., Vishesh Handa wrote: How about we change the cmake file to KF5KFileMetaDataConfig.cmake instead? This way there will be no conflicts, and it will be consistent with the rest of the frameworks as well? Aleix Pol Gonzalez wrote: I agree it's the best way, the only problem being tha it's actually not a framework, at least according to the list of frameworks and projects.kde.org. Vishesh Handa wrote: Yes. But it eventually will be. This way it is easily co-installable, and there are fewer renames in the future. We already have a KF5::FileMetaData alias. Aleix Pol Gonzalez wrote: I'll give the shipit, because I'm aware of this being done in similar cases. Please make sure everything builds when pushing this. Sounds good, I'll rename the file. Should the library also be renamed? As Baloo also conflicts, should I rename Baloo the same way, and should its library also be renamed? Or just append a 5 to CMake file? - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/#review59771 --- On June 4, 2014, 2:28 a.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/ --- (Updated June 4, 2014, 2:28 a.m.) Review request for Plasma, Jonathan Riddell and Vishesh Handa. Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334 http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334 Repository: kfilemetadata Description --- I've posted this RR as an RFC about the general structure of this idea. I just choose KFileMetaData as that is what my package manager conflicted over first. Ideally I want to push this change to any needed repositories for Plasma Next. As far as I understand the ability for Plasma Next and KDE4 application to be co-installed, all libraries should be co-installable except as listed on this page: http://community.kde.org/Plasma/Coinstallability . However, on source based distributions, such as Gentoo, to have both the KDE4 and KF5 versions simultaneously installed requires that the development files are also co-installable. As mentioned on this Gentoo bug[1], the header files are trivially dealt with, and the library simlink will probably be a downstream specific solution (as CMake doesn't require it for compiling). However, the CMake configuration files are another matter. This is take one of trying to fix this issue. If a different naming scheme, or if some different CMake trickery is desired I'll see about changing things to that, otherwise I think this is the simple and easy solution. I also volunteer to go through all the dependent packages and have patches ready (as best as I am able), as well as fix up any build failures that occur due to this change. Only find_package calls need modification, targets are left alone. [1] https://bugs.gentoo.org/show_bug.cgi?id=512334 Diffs - src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 Diff: https://git.reviewboard.kde.org/r/118512/diff/ Testing --- Tested compiling Baloo against a system install with this patch applied. Baloo sucessfully linked against the KF5 version and all Baloo tests ran to completion. All KFileMetaData unit tests passed too ;) Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118388: rename systemsettings binary to systemsettings5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118388/#review59811 --- One other thing that conflicts between the two versions is the systemsettings view library. I think just a soname bump is enough to handle it. - Matthew Dawson On May 28, 2014, 3:32 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118388/ --- (Updated May 28, 2014, 3:32 p.m.) Review request for Plasma and Ben Cooksley. Repository: systemsettings Description --- while workspace might not be targeted to co-exist with 4.x variant - systemsettings should IMHO be able to co-exist. not only workspace components are adjusting in there, and telling people to do kcmshell$notinstalledvariant $wantedkcm is very user-unfriendly... one TODO if this gets a green light, is to rename desktop files, so people know which variant they are opening. Diffs - app/systemsettings.desktop 5f27318 app/kdesystemsettings.desktop 946d498 app/CMakeLists.txt c45f7e7 Diff: https://git.reviewboard.kde.org/r/118388/diff/ Testing --- Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 Beta 2 tars
On June 5, 2014 03:47:59 PM Jonathan Riddell wrote: Tars are up for Plasma 5 Beta 2, please try them out and let me know of problems. I've renamed baloo and milou to have -kf5 in the tar name as you may well want the kdelibs4 versions around. Also kfilemetadata as kfilemetadata5. Regarding this, for source based distributions baloo/kfilemetadata can't be co-installed with there kdelibs4 version as the development files conflict, the main problem being the CMake files. I posted an RR here: https://git.reviewboard.kde.org/r/118512/ to try and fix that. Is this acceptable? Otherwise Plasma Next and the rest of KDE SC 4.x can't really be co-installed (especially KDEPIM!) Thanks, -- Matthew smime.p7s Description: S/MIME cryptographic signature ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118512: RFC: Rename CMake configuration files to KFileMetaData5*
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118512/ --- Review request for Plasma, Jonathan Riddell and Vishesh Handa. Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334 http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334 Repository: kfilemetadata Description --- I've posted this RR as an RFC about the general structure of this idea. I just choose KFileMetaData as that is what my package manager conflicted over first. Ideally I want to push this change to any needed repositories for Plasma Next. As far as I understand the ability for Plasma Next and KDE4 application to be co-installed, all libraries should be co-installable except as listed on this page: http://community.kde.org/Plasma/Coinstallability . However, on source based distributions, such as Gentoo, to have both the KDE4 and KF5 versions simultaneously installed requires that the development files are also co-installable. As mentioned on this Gentoo bug[1], the header files are trivially dealt with, and the library simlink will probably be a downstream specific solution (as CMake doesn't require it for compiling). However, the CMake configuration files are another matter. This is take one of trying to fix this issue. If a different naming scheme, or if some different CMake trickery is desired I'll see about changing things to that, otherwise I think this is the simple and easy solution. I also volunteer to go through all the dependent packages and have patches ready (as best as I am able), as well as fix up any build failures that occur due to this change. Only find_package calls need modification, targets are left alone. [1] https://bugs.gentoo.org/show_bug.cgi?id=512334 Diffs - src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 Diff: https://git.reviewboard.kde.org/r/118512/diff/ Testing --- Tested compiling Baloo against a system install with this patch applied. Baloo sucessfully linked against the KF5 version and all Baloo tests ran to completion. All KFileMetaData unit tests passed too ;) Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/ --- (Updated May 31, 2014, 10:33 p.m.) Review request for KDE Frameworks, Plasma and Ivan Čukić. Changes --- Updating the RR to match what I push. I changed the option name to match what is in master, and re-verified everything installs as appropriate. Repository: kactivities Description --- To allow for the library to be co-installed with the frameworks version, allow the daemon to be disabled. I'm not sure if this is the best way to do this. If there is any better way, I'll update the patch as appropriate. Diffs (updated) - src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 Diff: https://git.reviewboard.kde.org/r/118340/diff/ Testing --- Visually inspected install directories. Seems to remove only what is necessary. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/ --- (Updated June 1, 2014, 2:34 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Plasma and Ivan Čukić. Repository: kactivities Description --- To allow for the library to be co-installed with the frameworks version, allow the daemon to be disabled. I'm not sure if this is the best way to do this. If there is any better way, I'll update the patch as appropriate. Diffs - src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 Diff: https://git.reviewboard.kde.org/r/118340/diff/ Testing --- Visually inspected install directories. Seems to remove only what is necessary. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/ --- (Updated May 30, 2014, 11:42 p.m.) Review request for KDE Frameworks, Plasma and Ivan Čukić. Changes --- Change the macro_optional_add_subdirectory to a proper option. This also disables the KCM when the daemon is disabled. Repository: kactivities Description --- To allow for the library to be co-installed with the frameworks version, allow the daemon to be disabled. I'm not sure if this is the best way to do this. If there is any better way, I'll update the patch as appropriate. Diffs (updated) - src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 Diff: https://git.reviewboard.kde.org/r/118340/diff/ Testing --- Visually inspected install directories. Seems to remove only what is necessary. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.
On May 29, 2014, 10:57 a.m., David Edmundson wrote: This doesn't look great to me. We'd have to release another 4.x. Is this too big for the KDE 4.13.x releases? It doesn't change the default behaviour, and as discussed in: https://git.reviewboard.kde.org/r/115602/ , this is the only way to have a kactivities installed from both the KDE4 releases and frameworks. If it isn't wanted, I'll push it into my distribution (Gentoo) as a downstream patch. But, I have a feeling most distributions will do this, wasting effort. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/#review58731 --- On May 27, 2014, 1:27 a.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/ --- (Updated May 27, 2014, 1:27 a.m.) Review request for KDE Frameworks, Plasma and Ivan Čukić. Repository: kactivities Description --- To allow for the library to be co-installed with the frameworks version, allow the daemon to be disabled. I'm not sure if this is the best way to do this. If there is any better way, I'll update the patch as appropriate. Diffs - src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 Diff: https://git.reviewboard.kde.org/r/118340/diff/ Testing --- Visually inspected install directories. Seems to remove only what is necessary. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.
On May 29, 2014, 11:02 a.m., Alex Merry wrote: Did you try compiling this? Because that macro doesn't exist any more - there is an ecm_optional_add_subdirectory() in ECM if you include(ECMOptionalAddSubdirectory), though. However, I think an explicit option(), with a useful help-text, would be better. Alex Merry wrote: Ah, seeing David's comment made me realise I hadn't clocked the branch (I generally assume anything the kdeframeworks group has been added to is a frameworks branch). Although my point still stands about using option() to get a more useful help-text. Sorry for the confusion, I wasn't sure where exactly to address the RR, so I addressed it to all the places that seemed relevant. If David is ok with this patch, and it has a chance of going in I'll change it to use an explicit option. I originally took the path of least resistance, as most users wouldn't see this or care. But the explicit option would make the option definitely easier to understand. - Matthew --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/#review58733 --- On May 27, 2014, 1:27 a.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/ --- (Updated May 27, 2014, 1:27 a.m.) Review request for KDE Frameworks, Plasma and Ivan Čukić. Repository: kactivities Description --- To allow for the library to be co-installed with the frameworks version, allow the daemon to be disabled. I'm not sure if this is the best way to do this. If there is any better way, I'll update the patch as appropriate. Diffs - src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 Diff: https://git.reviewboard.kde.org/r/118340/diff/ Testing --- Visually inspected install directories. Seems to remove only what is necessary. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 105312: Add missing email addresses back into add widget tooltip.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/105312/ --- (Updated May 27, 2014, 2:27 p.m.) Status -- This change has been discarded. Review request for Plasma, Ivan Čukić and Marco Martin. Repository: kde-workspace Description --- When the QML port of the add widget dialog occured, the creator's email address got chopped off. This commit fixes a bug hidding the email address, and also starts displaying it again in the tooltip. There are a couple of issue left with this patch: 1) I have to disable wrapping, otherwise the text wraps at odd points for no reason (it fits fine otherwise). 2) The link currently doesn't work as I'm not sure how to hook it up to send mail. Should it be left as is, or just remove the link for 4.9 and update with a link for 4.10? Diffs - libs/plasmagenericshell/widgetsexplorer/package/contents/ui/Tooltip.qml ba804fd006496ee4a7118e97fe44038f0617eec7 libs/plasmagenericshell/widgetsexplorer/plasmaappletitemmodel_p.h e745ef58533ab0e22d2109d5beeff6c29c4d18b4 Diff: https://git.reviewboard.kde.org/r/105312/diff/ Testing --- Tested locally in Xephyr. The tooltip now contains the email address. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118340/ --- Review request for KDE Frameworks, Plasma and Ivan Čukić. Repository: kactivities Description --- To allow for the library to be co-installed with the frameworks version, allow the daemon to be disabled. I'm not sure if this is the best way to do this. If there is any better way, I'll update the patch as appropriate. Diffs - src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 Diff: https://git.reviewboard.kde.org/r/118340/diff/ Testing --- Visually inspected install directories. Seems to remove only what is necessary. Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request - Amend GPLv2+ license - Exemption link clause - for KDE weather engine/ions (weather related only) for BlackBerry 10/QNX
On January 17, 2013 08:06:05 PM Shawn Starr wrote: Hello folks, I need to get approvals from those who made some changes to the engine code, the change is to append the exemption clause to GPLv2+ so that I can link the binaries to QNX's libc / and RIM's cascades libs, as these are considered core to the OS. I also want to know if we can dual copyright with the KDE Foundation so that even if the code diverges the changes can flow back and forth between the QNX/BB10 git repo and KDE's git repository. So to reiterate, the code remains GPLv2+ but just gains the exemption clause (see here: http://en.wikipedia.org/wiki/GPL_linking_exception). What are your thoughts on this? Can this all be done easy? For the wording, I would like us to use the most liberal one so that there remains no issues/restrictions to anyone. Thanks, Shawn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Sorry if I don't understand what you are asking for, but to link GPL software against system libraries doesn't require exceptions (see http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException ). If you are linking other applications against the engine code, then the exceptions is required. (I don't have any copyrights over the code, so the decision doesn't effect me) Matthew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request - Amend GPLv2+ license - Exemption link clause - for KDE weather engine/ions (weather related only) for BlackBerry 10/QNX
On January 17, 2013 09:51:45 PM Shawn Starr wrote: On Thursday, January 17, 2013 09:47:27 PM Matthew Dawson wrote: On January 17, 2013 08:06:05 PM Shawn Starr wrote: Hello folks, I need to get approvals from those who made some changes to the engine code, the change is to append the exemption clause to GPLv2+ so that I can link the binaries to QNX's libc / and RIM's cascades libs, as these are considered core to the OS. snip Sorry if I don't understand what you are asking for, but to link GPL software against system libraries doesn't require exceptions (see http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException ). If you are linking other applications against the engine code, then the exceptions is required. The libraries being linked into are not GPL however thats the need for the exemption clause. QNX's libc and RIM's cascades are not GPL/LGPL libraries. Thanks, Shawn. I understood that. However, as the GPL faq states, GPL programs can link to system libraries that are closed source. libc (assuming that is the C library) is definitly a system library, and I assume cascades is one too (it's stated in the GPL what the definition is). This is why you don't need an exception for GPL software on Windows. The exceptions you talk about are for applications (a third party) linking against libraries (being the weather data engines), thus creating a LGPL like license. The wikipedia article you linked to describes this in detail. Now, if you are looking for the code to be LGPL like, then I'd think it be easiest to re-license the code to the LGPL. If you simply need to link to system libraries, then no exception/re-licensing is necessary. Matthew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On Tuesday 20 December 2011 17:54:02 Martin Gräßlin wrote: Up to now nobody gave a proper reason *why* we should add a back button. Just because we can is no reason, sorry. First, I understand that the back button is gone and I'm not advocating its return. I do think I understand why there is a backlash about this option, and it stems from two points: 1) The back button was a much larger button to hit. According to Fitt's Law[1], the smaller a target is to hit, the longer it takes. The breadcrumbs, being smaller, decreases the speed at which someone can hit the target. It is readily apparent to me, as I only recently got introduced to it. 2) The position of the breadcrumbs is on the upper right hand corner. People will first look for information to the upper left hand part of the screen. With the breadcrumbs positioned where they are, its first of all hard to find compared to the back button. I can't remember if people brought up with RTL languages see upper right hand first, but at least for LTR it is. Based upon these two points, a couple of simple solutions present themselves: 1) Make the text a little bigger. Since users will approach the breadcrumbs from the bottom, increasing the height will help them hit the button easier. This will probably require some fiddling with to ensure the best possible result. 2) At least for LTR, move the breadcrumbs over to the left hand side. This will help users more easily find the breadcrumbs and choose an option. This also helps with selection, as any overshoot to return to the beginning, when approached from the right, will hit the edge of the screen and avoid too much backtracking, making it easier for users to hit. Note this only applies in Kickoff's default location, but I don't think most people will have an issue. Thoughts? If these ideas sound useful, I'll try to cook up a patch to implment them. Matthew [1] http://en.wikipedia.org/wiki/Fitts%27s_law ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities overview, take N
On Tuesday 13 October 2009 13:09:26 Aaron J. Seigo wrote: On October 12, 2009, Chani wrote: * in a-containment-per-virtual-desktop mode (which i'm starting to feel small amounts of regret over offering ... but maybe i'm just being pessimistic :) the Choose Activities would be per-virtual-desktop. if you wanted to migrate an activity from one desktop to another, you'd have to store it first. the more i think about per-virtual-desktop containments the more i cringe, though. this paragraph makes me cringe. I don't get it and I'm not sure I want to. yeah, same here. Thinking about the a-containment-per-virtual-desktop mode, I feel like I use that feature as a substitute for the missing ability of having nepomuk tied activities. I'd think once you have activities proper this feature will seem (and feel) redundant. Maybe the better option would be to simply remove the a-containment-per-virtual-desktop mode once activities are done? Another major benefit from this feature is the easy switching between different containments. I am sure there are better ways to switch containments then having virtual desktops tied to containments, so I doubt this is any reason to retain them. Matthew signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: big revamp of Device Notifier
On Friday 11 September 2009 05:56:52 Giulio Camuffo wrote: On 2009-09-10 18:18:27, Jacopo De Simoi wrote: /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui, line 63 http://reviewboard.kde.org/r/1370/diff/5/?file=10960#file10960line63 I am not a native speaker either.. but this the seems strange to me well, i tried with google translate but it leaves me quite confused: http://translate.google.it/translate_t?hl=itie=UTF-8text=mostra+le+periferiche+rimovibilisl=ittl=en#it|en|mostra%20anche%20le%20periferiche%20rimovibili and http://translate.google.it/translate_t?hl=itie=UTF-8text=mostra+le+periferiche+rimovibilisl=ittl=en#it|en|mostra%20le%20periferiche%20rimovibili. I suppose we need to wait for a native speaker :) IMH(native speaker's)O, that the should not be there, as it makes it sound like there is only one particular removable device that the user wishes to be shown. Matthew signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add fade effect to wallpaper plugin.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/195/ --- (Updated 2009-03-06 12:09:15.235406) Review request for Plasma. Changes --- * Change from a QTimeline to Plasma::Animator * Destroy Pixmaps when the animation is finished. Summary --- This patch makes the wallpaper plugin fade out the old wallpaper when it changes. Currently the effect only works when in slideshow mode. Video Demo: http://mjdsystems.ca/fadedemo.ogv This addresses bug 168731. https://bugs.kde.org/show_bug.cgi?id=168731 Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.h 933647 /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 933647 Diff: http://reviewboard.kde.org/r/195/diff Testing --- Locally in Xephyr. Thanks, Matthew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add fade effect to wallpaper plugin.
Hey,
On Monday 02 March 2009 15:06:35 Aaron J. Seigo wrote:
snip
comments on patch (besides thanks! always great to receive patches from new
faces):
Thanks for the comments!
- coding style. {s for methods start on their own line (see updateFadedImage)
and there is a space between the keyword and the opening ( in a conditional:
If ( not if( and ) { not ){.
Fixed!
- it should be using Plasma::Animator for its timer and a CustomTimer so this
can be turned off by policy and share the global timer for this. using your
own QTimeLine is, in general, a no-go.
I just looked at Plasma::Animator. Would I use the
Plasma::Animator::CustomAnimation function to replace the QTimeLine? Also I
looked through both the documentation and the sources, and I can't find a
mention of CustomTimer. I'm just wondering what it is.
- it seems that there should be a more performant way of doing this than
creating a third pixmap that is the size of the end result, painting into it
and then painting another into it! i'd suggest trying something like just
painting both images into the exposed rect as passed into the paint method
using the current alpha. if that produces acceptable results, i'd say go for
it.
After playing around with a simple demo with two colours, it appears that the 3
pixmap method works best. I pulled most of the code from
http://techbase.kde.org/Development/Tutorials/Graphics/Performance#QPixmap::setAlphaChannel.28.29
. While 3 pixmaps does seem like overkill, it seems to be the only way that
works. I could probably get away with two pixmaps and QPainter.setOpacity, but
as the above link says that is a performance killer. I tested different
combinations of methods. If you have any other suggestion, I'm happy to try
them!
* remember to free the other pixmap when the animation is done so it isn't
sitting around in memory. assigning a QPixmap() to it should be enough.
Will do.
regardless of how its done (other than in hardware), doing full screen
repaints isn't going to be precisely brilliant for performance, but as an
option it's pretty nice :) which reminds me to check the default caching mode
for Plasma::Containment with regards to performance (both memory usage as
well
as speed)
During testing, it appears (at least for QTimeLine) that it skips frames if it
takes to long to repaint. So on slower machines it will work, it will just be
choppy.
Matthew
--
/*
* Buddy system. Hairy. You really aren't expected to understand this
*
*/
-- From /usr/src/linux/mm/page_alloc.cA
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add fade effect to wallpaper plugin.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/195/ --- Review request for Plasma. Summary --- This patch makes the wallpaper plugin fade out the old wallpaper when it changes. Currently the effect only works when in slideshow mode. Video Demo: http://mjdsystems.ca/fadedemo.ogv This addresses bug 168731. https://bugs.kde.org/show_bug.cgi?id=168731 Diffs - /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.h 932504 /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 932504 Diff: http://reviewboard.kde.org/r/195/diff Testing --- Locally in Xephyr. Thanks, Matthew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add fade effect to wallpaper plugin.
Hello,
Unfortunately, reviewboard is not accepting this updated diff, so I'm posting
it here. I'm not sure why I thought it didn't work with single images, but it
does now. It also works in the configuration dialog box :).
Matthew
On Thursday 26 February 2009 16:02:31 Artur de Souza (MoRpHeUz) wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/195/#review287
---
Hmm...the idea is pretty nice. Why it doesn't work for single images
wallpapers (just slideshow) ? Hehe, and this is the typical feature that is
trivial to do with Qt Kinetic ;)
Cheers
- Artur
On 2009-02-26 12:24:44, Matthew Dawson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/195/
---
(Updated 2009-02-26 12:24:44)
Review request for Plasma.
Summary
---
This patch makes the wallpaper plugin fade out the old wallpaper when it
changes. Currently the effect only works when in slideshow mode.
Video Demo:
http://mjdsystems.ca/fadedemo.ogv
This addresses bug 168731.
https://bugs.kde.org/show_bug.cgi?id=168731
Diffs
-
/trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.h 932504
/trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 932504
Diff: http://reviewboard.kde.org/r/195/diff
Testing
---
Locally in Xephyr.
Thanks,
Matthew
Index: workspace/plasma/wallpapers/image/image.cpp
===
--- workspace/plasma/wallpapers/image/image.cpp (revision 932504)
+++ workspace/plasma/wallpapers/image/image.cpp (working copy)
@@ -32,15 +32,20 @@
Image::Image(QObject *parent, const QVariantList args)
: Plasma::Wallpaper(parent, args),
+ m_fadeTimeLine(1500),
m_currentSlide(-1),
m_model(0),
m_dialog(0),
m_rendererToken(-1),
m_randomize(true)
{
+//Start at frame 1 otherwise their is a nasty black flicker.
+m_fadeTimeLine.setFrameRange(1, 255);
+
qRegisterMetaTypeQImage(QImage);
connect(m_renderer, SIGNAL(done(int, QImage)), this, SLOT(updateBackground(int, QImage)));
connect(m_timer, SIGNAL(timeout()), this, SLOT(nextSlide()));
+connect(m_fadeTimeLine, SIGNAL(frameChanged(int)), this, SLOT(updateFadedImage(int)));
}
Image::~Image()
@@ -233,6 +238,12 @@
// bitmapBackground already has the size of the viewport)
painter-drawPixmap(exposedRect, m_pixmap, exposedRect);
+if(m_fadeTimeLine.state() == QTimeLine::Running !m_oldFadedPixmap.isNull()){
+// Put old faded image on top.
+painter-setCompositionMode(QPainter::CompositionMode_SourceAtop);
+painter-drawPixmap(exposedRect, m_oldFadedPixmap, exposedRect);
+}
+
// restore transformation and composition mode
painter-restore();
}
@@ -525,9 +536,19 @@
void Image::updateBackground(int token, const QImage img)
{
+
if (m_rendererToken == token) {
+
+m_oldPixmap = m_pixmap;
+if(m_oldPixmap.isNull()){
+m_oldPixmap = QPixmap(img.size());
+m_oldPixmap.fill(m_color);
+}
+m_oldFadedPixmap = m_oldPixmap;
+
m_pixmap = QPixmap::fromImage(img);
-emit update(boundingRect());
+
+m_fadeTimeLine.start();
suspendStartup(false);
}
}
@@ -555,4 +576,22 @@
}
}
+void Image::updateFadedImage(int frame){
+
+//Create the faded image.
+m_oldFadedPixmap.fill(Qt::transparent);
+
+QPainter p;
+p.begin(m_oldFadedPixmap);
+p.drawPixmap(0, 0, m_oldPixmap);
+
+p.setCompositionMode(QPainter::CompositionMode_DestinationIn);
+p.fillRect(m_oldFadedPixmap.rect(), QColor(0, 0, 0, 255-frame));//255*((150 - frame)/150)));
+
+p.end();
+
+emit update(boundingRect());
+
+}
+
#include image.moc
Index: workspace/plasma/wallpapers/image/image.h
===
--- workspace/plasma/wallpapers/image/image.h (revision 932504)
+++ workspace/plasma/wallpapers/image/image.h (working copy)
@@ -12,6 +12,7 @@
#define IMAGE_HEADER
#include QTimer
+#include QTimeLine
#include QPixmap
#include QStringList
#include Plasma/Wallpaper
@@ -49,6 +50,7 @@
void showFileDialog();
void updateScreenshot(QPersistentModelIndex index);
void removeBackground(const QString path);
+void updateFadedImage(int frame);
protected:
void init(const KConfigGroup config);
@@ -76,6 +78,9 @@
QListBackground * m_slideshowBackgrounds;
QTimer m_timer;
QPixmap m_pixmap;
+QPixmap m_oldPixmap;
+QPixmap m_oldFadedPixmap
Re: Review Request: Add the ability for applets to change autohide timeout value
On Friday 09 January 2009 18:10:25 Chani wrote: On January 9, 2009 14:13:28 Matthew Dawson wrote: On 2008-12-30 17:07:07, Aaron Seigo wrote: what is the use case? Some applets may update faster then 3 seconds (such as systemloadviewer). This would allow them to set an update interval so they may still use the auto-hide feature. huh? what does updated data have to do with autohide? you can update the tooltip data without hiding it - look at the clock tooltip when the clock is showing seconds. Currently if you update the tooltip's content faster then three seconds, the tooltip will never autohide. This occurs because the timer counting the three seconds resets when data is updated. The problem is that the tooltip doesn't go away, not that it never appears. Matthew -- A feature is nothing more than a bug with seniority. -- Unknown source signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
