Review Request 119984: more plasmashell code cleaning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119984/ --- Review request for Plasma. Repository: plasma-workspace Description --- Three commits that clean up some code warts in plasmashell. Diffs - shell/main.cpp bb63bdc85ff2a003fa4a5c4e2320383db98da087 shell/shellcorona.h d559fcdc99c0066d552e013d3fea249147f50b5f shell/shellcorona.cpp 84442ae60cf0f576a077e770ceae82a17721a456 Diff: https://git.reviewboard.kde.org/r/119984/diff/ Testing --- Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119984: more plasmashell code cleaning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119984/#review65466 --- Ship it! Ship It! - David Edmundson On Aug. 29, 2014, 7:43 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119984/ --- (Updated Aug. 29, 2014, 7:43 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Three commits that clean up some code warts in plasmashell. Diffs - shell/main.cpp bb63bdc85ff2a003fa4a5c4e2320383db98da087 shell/shellcorona.h d559fcdc99c0066d552e013d3fea249147f50b5f shell/shellcorona.cpp 84442ae60cf0f576a077e770ceae82a17721a456 Diff: https://git.reviewboard.kde.org/r/119984/diff/ Testing --- Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119983: Use font metrics to scale icons for high dpi outputs
On Aug. 29, 2014, 1:11 a.m., David Edmundson wrote: src/declarativeimports/core/units.cpp, lines 197-198 https://git.reviewboard.kde.org/r/119983/diff/1/?file=308044#file308044line197 I'm confused. gridUnit is based on QGuiApplication::font() and we generate a ratio comparing it against QGuiApplication::font() won't that always result in the same constant? Not quite, the grid unit uses boundingRect.height(), which is in pixels, while this uses pointSize(), that's not in pixels. If I understand it correctly, same point size can have different pixel sizes depending on things. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/#review65459 --- On Aug. 29, 2014, 1:03 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/ --- (Updated Aug. 29, 2014, 1:03 a.m.) Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Vishesh Handa. Bugs: 337712 and 338308 http://bugs.kde.org/show_bug.cgi?id=337712 http://bugs.kde.org/show_bug.cgi?id=338308 Repository: plasma-framework Description --- Use font metrics to scale icons for high dpi outputs QScreen, through EDID reports bogus values for physicalDotsPerInch*(). This leads to oversized icons on monitors with bogus edid information. This patch changes the ratio underlying to the icon sizing for displays with a DPI 96 * 1.5 to use the ratio between the font as rendered (its effective pixelSize, essentially) to scale the icon sizes up. As we rely on proper font metrics throughout already, this should bring sizing in line with the font, which is something that makes sense as it means we're sharing the underlying mechanism (font metrics) for sizing in different areas. The downside of this patch is that we're essentially working around an issue that should be fixed in the hardware, the monitor's edid. Unrealistic. print dpi / sizing in dpitest Print out some useful information to deduce dpi and pixel sizing. David, and Kai Uwe, Vishesh (since I know you have a high DPI displays), could you run this patch for a bit and check if it works for you, too? I've pushed it to plasma-framework[sebas/dpi] for your git convenience. Diffs - src/declarativeimports/core/units.h ba481781a04a54cb77f99048d3d400fdae617b38 src/declarativeimports/core/units.cpp 56c0b55427c128beff5f8d18c37847a435f194c0 tests/dpi/dpitest.cpp c3d2c3e6821fd79fc8b5ed0b3559a5870f88aa36 Diff: https://git.reviewboard.kde.org/r/119983/diff/ Testing --- Ran Plasma Desktop, no apparent problems (on this hardware, which worked, anyway). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119983: Use font metrics to scale icons for high dpi outputs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/#review65472 --- shouldn't be m_gridunit be calculated from fontPixelRatio as well then? to be really sure the two things are calculated with the same logic - Marco Martin On Aug. 28, 2014, 11:03 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/ --- (Updated Aug. 28, 2014, 11:03 p.m.) Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Vishesh Handa. Bugs: 337712 and 338308 http://bugs.kde.org/show_bug.cgi?id=337712 http://bugs.kde.org/show_bug.cgi?id=338308 Repository: plasma-framework Description --- Use font metrics to scale icons for high dpi outputs QScreen, through EDID reports bogus values for physicalDotsPerInch*(). This leads to oversized icons on monitors with bogus edid information. This patch changes the ratio underlying to the icon sizing for displays with a DPI 96 * 1.5 to use the ratio between the font as rendered (its effective pixelSize, essentially) to scale the icon sizes up. As we rely on proper font metrics throughout already, this should bring sizing in line with the font, which is something that makes sense as it means we're sharing the underlying mechanism (font metrics) for sizing in different areas. The downside of this patch is that we're essentially working around an issue that should be fixed in the hardware, the monitor's edid. Unrealistic. print dpi / sizing in dpitest Print out some useful information to deduce dpi and pixel sizing. David, and Kai Uwe, Vishesh (since I know you have a high DPI displays), could you run this patch for a bit and check if it works for you, too? I've pushed it to plasma-framework[sebas/dpi] for your git convenience. Diffs - src/declarativeimports/core/units.h ba481781a04a54cb77f99048d3d400fdae617b38 src/declarativeimports/core/units.cpp 56c0b55427c128beff5f8d18c37847a435f194c0 tests/dpi/dpitest.cpp c3d2c3e6821fd79fc8b5ed0b3559a5870f88aa36 Diff: https://git.reviewboard.kde.org/r/119983/diff/ Testing --- Ran Plasma Desktop, no apparent problems (on this hardware, which worked, anyway). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119983: Use font metrics to scale icons for high dpi outputs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/#review65473 --- I'm on a standard pleb monitor, I get: $ ./dpitest dpitest(8664)/(default) Plasma::DPITest::runMain: DPI test runs: dpitest(8664)/(default) Plasma::DPITest::runMain: font.pixelSize: -1 dpitest(8664)/(default) Plasma::DPITest::runMain: font.pointSize: 9 dpitest(8664)/(default) Plasma::DPITest::runMain: devicePixelRatio: 0.963947 dpitest(8664)/(default) Plasma::DPITest::runMain: pointSize * devicePixelRatio: 8.67552 dpitest(8664)/(default) Plasma::DPITest::runMain: dpi: 92.5389 dpitest(8664)/(default) Plasma::DPITest::runMain: gridUnit: 14 dpitest(8664)/(default) Plasma::DPITest::runMain: gridUnit / pointSize : 1.6 I should have a ratio of ~1 I think, but it does seem to look OK. I'll pester vishesh to run it too. - David Edmundson On Aug. 28, 2014, 11:03 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/ --- (Updated Aug. 28, 2014, 11:03 p.m.) Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Vishesh Handa. Bugs: 337712 and 338308 http://bugs.kde.org/show_bug.cgi?id=337712 http://bugs.kde.org/show_bug.cgi?id=338308 Repository: plasma-framework Description --- Use font metrics to scale icons for high dpi outputs QScreen, through EDID reports bogus values for physicalDotsPerInch*(). This leads to oversized icons on monitors with bogus edid information. This patch changes the ratio underlying to the icon sizing for displays with a DPI 96 * 1.5 to use the ratio between the font as rendered (its effective pixelSize, essentially) to scale the icon sizes up. As we rely on proper font metrics throughout already, this should bring sizing in line with the font, which is something that makes sense as it means we're sharing the underlying mechanism (font metrics) for sizing in different areas. The downside of this patch is that we're essentially working around an issue that should be fixed in the hardware, the monitor's edid. Unrealistic. print dpi / sizing in dpitest Print out some useful information to deduce dpi and pixel sizing. David, and Kai Uwe, Vishesh (since I know you have a high DPI displays), could you run this patch for a bit and check if it works for you, too? I've pushed it to plasma-framework[sebas/dpi] for your git convenience. Diffs - src/declarativeimports/core/units.h ba481781a04a54cb77f99048d3d400fdae617b38 src/declarativeimports/core/units.cpp 56c0b55427c128beff5f8d18c37847a435f194c0 tests/dpi/dpitest.cpp c3d2c3e6821fd79fc8b5ed0b3559a5870f88aa36 Diff: https://git.reviewboard.kde.org/r/119983/diff/ Testing --- Ran Plasma Desktop, no apparent problems (on this hardware, which worked, anyway). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119984: more plasmashell code cleaning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119984/#review65474 --- Ship it! Ship It! - Marco Martin On Aug. 29, 2014, 7:43 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119984/ --- (Updated Aug. 29, 2014, 7:43 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Three commits that clean up some code warts in plasmashell. Diffs - shell/main.cpp bb63bdc85ff2a003fa4a5c4e2320383db98da087 shell/shellcorona.h d559fcdc99c0066d552e013d3fea249147f50b5f shell/shellcorona.cpp 84442ae60cf0f576a077e770ceae82a17721a456 Diff: https://git.reviewboard.kde.org/r/119984/diff/ Testing --- Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Schedule
I've tidied up the Plasma 5 release schedule https://techbase.kde.org/Schedules/Plasma_5 Frameworks https://techbase.kde.org/Schedules/Frameworks tags on first Sat or month and release on following Thursday. Plasma tags on Frameworks release Thursdays and release on following Tuesday (with Beta releases two weeks before final). Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119984: more plasmashell code cleaning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119984/ --- (Updated Aug. 29, 2014, 11:20 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- Three commits that clean up some code warts in plasmashell. Diffs - shell/main.cpp bb63bdc85ff2a003fa4a5c4e2320383db98da087 shell/shellcorona.h d559fcdc99c0066d552e013d3fea249147f50b5f shell/shellcorona.cpp 84442ae60cf0f576a077e770ceae82a17721a456 Diff: https://git.reviewboard.kde.org/r/119984/diff/ Testing --- Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119988: Package structure cleanups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119989: PackageStructure plugins in plasma-workspaces
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119989/ --- Review request for Plasma. Repository: plasma-workspace Description --- This patchset introduces the use of PackageStructure plugins to plasma-workspace, allowing the removal of ShellPluginLoader everywhere. It also fixes some strange use of PackageStructure in the share DataEngine and updates that PackageStructure to use the JSON-based loading. With this changeset Plasma/Shell, Plasma/LookAndFeel and Plasma/Wallpaper are all plugins and accessible from everywhere that needs them via Plasma::PluginLoader. Diffs - dataengines/share/share_package.cpp 13f41def3abd5ccf57b8745e3fd6956d10377a7a dataengines/share/shareprovider.h c9159cdde6a858fbdca57ad7c5aa258028fd9ac3 dataengines/share/shareprovider.cpp fd1812fa1263cdf9df7d4340c681a63f8455ce07 shell/packageplugins/shell/shellpackage.h PRE-CREATION shell/packageplugins/shell/shellpackage.cpp PRE-CREATION shell/packageplugins/wallpaper/CMakeLists.txt PRE-CREATION ksmserver/screenlocker/greeter/greeterapp.cpp 92e839091412585dddc369d5a4a3beace39e92ae ksmserver/shellpluginloader.h 6f13d493a800a7479711ef3549cfd9362a593778 ksmserver/shutdowndlg.cpp b4e59a387e5bf857db6314cf1b879e6a775e9f99 lookandfeelaccess/lookandfeelaccess.cpp 474e06d7b189fc368d1f9ba45426ea30392e2a71 lookandfeelaccess/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda plasma-windowed/main.cpp 4e9263aad9736b93dc00e7fef74db54b39456cb6 plasma-windowed/plasma-windowed.desktop a462867d8a680d714490a0783f85902e373f26a1 plasma-windowed/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b plasma-windowed/plasmawindowedcorona.cpp 23bc60384ffbffec90b9cae5ddb6d35b1aaa1fc0 shell/CMakeLists.txt d67be9782de1faa9890bf85b8b2b517e15f12812 shell/main.cpp bb63bdc85ff2a003fa4a5c4e2320383db98da087 shell/osd.cpp 961c9ca3974337553bcefc1fc2c06222da9114e1 shell/packageplugins/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.h PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.cpp PRE-CREATION shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop PRE-CREATION shell/packageplugins/lookandfeel/CMakeLists.txt PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.h PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.cpp PRE-CREATION shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop PRE-CREATION shell/packageplugins/packages.h PRE-CREATION shell/packageplugins/packages.cpp PRE-CREATION shell/packageplugins/shell/CMakeLists.txt PRE-CREATION shell/packageplugins/shell/Messages.sh PRE-CREATION shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop PRE-CREATION dataengines/share/share_package.h dataengines/share/CMakeLists.txt 3d67b137f9a3e37453b8890d0d3c73e6469bae38 dataengines/share/data/CMakeLists.txt e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 dataengines/share/data/plasma-packagestructure-share.desktop dataengines/share/packagestructure/CMakeLists.txt PRE-CREATION dataengines/share/plugin_share_package.cpp c4e2f23f7a65ddc67a94c60dffa3f71701a46b8b shell/packageplugins/wallpaper/plasma-packagestructure-wallpaper.desktop PRE-CREATION shell/packageplugins/wallpaper/wallpaper.h PRE-CREATION shell/packageplugins/wallpaper/wallpaper.cpp PRE-CREATION shell/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b shell/shellcorona.h d559fcdc99c0066d552e013d3fea249147f50b5f shell/shellcorona.cpp 84442ae60cf0f576a077e770ceae82a17721a456 dataengines/share/shareservice.h 5fb533d06fc74a52c33e0c8e1052ec93ffc4e11f dataengines/share/shareservice.cpp 8442b6634e5e55f8717b9684dd41839df8d3d677 krunner/main.cpp 4d8cc31ff4d78c2daa0f9a6af247b3bd1c317ffa krunner/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda krunner/view.cpp 0d986e845e3b9821ef39a874d431a087e2390e8a Diff: https://git.reviewboard.kde.org/r/119989/diff/ Testing --- Ran a full Plasma Desktop session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65481 --- src/plasma/packagestructure.h https://git.reviewboard.kde.org/r/119988/#comment45738 would removing a #define count as a SIC? - David Edmundson On Aug. 29, 2014, 11:51 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 11:51 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65482 --- Ship it! +1 for removing shellpackage. good for plugin-ification - Marco Martin On Aug. 29, 2014, 11:51 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 11:51 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119989: PackageStructure plugins in plasma-workspaces
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119989/#review65479
---
dataengines/share/packagestructure/CMakeLists.txt
https://git.reviewboard.kde.org/r/119989/#comment45739
having the add_library in a different place to where we define
{sharepackage_SRCS} is a bit weird, can we move that alongside.
krunner/main.cpp
https://git.reviewboard.kde.org/r/119989/#comment45736
you don't want to re-add this.
(probably this is just an un-rebased diff?)
Looks ok to me, but I don't understand a lot of this package stuff.
- David Edmundson
On Aug. 29, 2014, 11:53 a.m., Aaron J. Seigo wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119989/
---
(Updated Aug. 29, 2014, 11:53 a.m.)
Review request for Plasma.
Repository: plasma-workspace
Description
---
This patchset introduces the use of PackageStructure plugins to
plasma-workspace, allowing the removal of ShellPluginLoader everywhere. It
also fixes some strange use of PackageStructure in the share DataEngine and
updates that PackageStructure to use the JSON-based loading.
With this changeset Plasma/Shell, Plasma/LookAndFeel and Plasma/Wallpaper are
all plugins and accessible from everywhere that needs them via
Plasma::PluginLoader.
Diffs
-
dataengines/share/share_package.cpp
13f41def3abd5ccf57b8745e3fd6956d10377a7a
dataengines/share/shareprovider.h c9159cdde6a858fbdca57ad7c5aa258028fd9ac3
dataengines/share/shareprovider.cpp
fd1812fa1263cdf9df7d4340c681a63f8455ce07
shell/packageplugins/shell/shellpackage.h PRE-CREATION
shell/packageplugins/shell/shellpackage.cpp PRE-CREATION
shell/packageplugins/wallpaper/CMakeLists.txt PRE-CREATION
ksmserver/screenlocker/greeter/greeterapp.cpp
92e839091412585dddc369d5a4a3beace39e92ae
ksmserver/shellpluginloader.h 6f13d493a800a7479711ef3549cfd9362a593778
ksmserver/shutdowndlg.cpp b4e59a387e5bf857db6314cf1b879e6a775e9f99
lookandfeelaccess/lookandfeelaccess.cpp
474e06d7b189fc368d1f9ba45426ea30392e2a71
lookandfeelaccess/shellpluginloader.h
9c0f62412eac4d1ad03c681325852d9efe25ccda
plasma-windowed/main.cpp 4e9263aad9736b93dc00e7fef74db54b39456cb6
plasma-windowed/plasma-windowed.desktop
a462867d8a680d714490a0783f85902e373f26a1
plasma-windowed/plasmaquick/shellpluginloader.h
ea0755e4abe841e33777d89cb12a5e689161e51b
plasma-windowed/plasmawindowedcorona.cpp
23bc60384ffbffec90b9cae5ddb6d35b1aaa1fc0
shell/CMakeLists.txt d67be9782de1faa9890bf85b8b2b517e15f12812
shell/main.cpp bb63bdc85ff2a003fa4a5c4e2320383db98da087
shell/osd.cpp 961c9ca3974337553bcefc1fc2c06222da9114e1
shell/packageplugins/CMakeLists.txt PRE-CREATION
shell/packageplugins/layouttemplate/CMakeLists.txt PRE-CREATION
shell/packageplugins/layouttemplate/layouttemplate.h PRE-CREATION
shell/packageplugins/layouttemplate/layouttemplate.cpp PRE-CREATION
shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
PRE-CREATION
shell/packageplugins/lookandfeel/CMakeLists.txt PRE-CREATION
shell/packageplugins/lookandfeel/lookandfeel.h PRE-CREATION
shell/packageplugins/lookandfeel/lookandfeel.cpp PRE-CREATION
shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop
PRE-CREATION
shell/packageplugins/packages.h PRE-CREATION
shell/packageplugins/packages.cpp PRE-CREATION
shell/packageplugins/shell/CMakeLists.txt PRE-CREATION
shell/packageplugins/shell/Messages.sh PRE-CREATION
shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop
PRE-CREATION
dataengines/share/share_package.h
dataengines/share/CMakeLists.txt 3d67b137f9a3e37453b8890d0d3c73e6469bae38
dataengines/share/data/CMakeLists.txt
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
dataengines/share/data/plasma-packagestructure-share.desktop
dataengines/share/packagestructure/CMakeLists.txt PRE-CREATION
dataengines/share/plugin_share_package.cpp
c4e2f23f7a65ddc67a94c60dffa3f71701a46b8b
shell/packageplugins/wallpaper/plasma-packagestructure-wallpaper.desktop
PRE-CREATION
shell/packageplugins/wallpaper/wallpaper.h PRE-CREATION
shell/packageplugins/wallpaper/wallpaper.cpp PRE-CREATION
shell/plasmaquick/shellpluginloader.h
ea0755e4abe841e33777d89cb12a5e689161e51b
shell/shellcorona.h d559fcdc99c0066d552e013d3fea249147f50b5f
shell/shellcorona.cpp 84442ae60cf0f576a077e770ceae82a17721a456
dataengines/share/shareservice.h 5fb533d06fc74a52c33e0c8e1052ec93ffc4e11f
dataengines/share/shareservice.cpp 8442b6634e5e55f8717b9684dd41839df8d3d677
krunner/main.cpp
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65481 --- On Aug. 29, 2014, 11:51 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 11:51 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119989: PackageStructure plugins in plasma-workspaces
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119989/ --- (Updated Aug. 29, 2014, 12:17 p.m.) Review request for Plasma. Changes --- Rebased on master; should be cleaner now. Repository: plasma-workspace Description --- This patchset introduces the use of PackageStructure plugins to plasma-workspace, allowing the removal of ShellPluginLoader everywhere. It also fixes some strange use of PackageStructure in the share DataEngine and updates that PackageStructure to use the JSON-based loading. With this changeset Plasma/Shell, Plasma/LookAndFeel and Plasma/Wallpaper are all plugins and accessible from everywhere that needs them via Plasma::PluginLoader. Diffs (updated) - shell/packageplugins/packages.h PRE-CREATION lookandfeelaccess/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda plasma-windowed/main.cpp 4e9263aad9736b93dc00e7fef74db54b39456cb6 plasma-windowed/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b shell/CMakeLists.txt d67be9782de1faa9890bf85b8b2b517e15f12812 shell/main.cpp 04e1fd168df15bced40bfd84b965fb6f4905ded6 shell/osd.cpp 961c9ca3974337553bcefc1fc2c06222da9114e1 shell/packageplugins/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.h PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.cpp PRE-CREATION shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop PRE-CREATION shell/packageplugins/lookandfeel/CMakeLists.txt PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.h PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.cpp PRE-CREATION shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop PRE-CREATION dataengines/share/data/CMakeLists.txt e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 dataengines/share/data/plasma-packagestructure-share.desktop dataengines/share/packagestructure/CMakeLists.txt PRE-CREATION dataengines/share/plugin_share_package.cpp c4e2f23f7a65ddc67a94c60dffa3f71701a46b8b dataengines/share/share_package.h dataengines/share/share_package.cpp 13f41def3abd5ccf57b8745e3fd6956d10377a7a dataengines/share/shareprovider.h c9159cdde6a858fbdca57ad7c5aa258028fd9ac3 dataengines/share/shareprovider.cpp fd1812fa1263cdf9df7d4340c681a63f8455ce07 dataengines/share/shareservice.h 5fb533d06fc74a52c33e0c8e1052ec93ffc4e11f dataengines/share/shareservice.cpp 8442b6634e5e55f8717b9684dd41839df8d3d677 krunner/main.cpp 408c5631a8007ac2617c7963cd83146dc4bbceeb krunner/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda krunner/view.cpp 0d986e845e3b9821ef39a874d431a087e2390e8a ksmserver/screenlocker/greeter/greeterapp.cpp 92e839091412585dddc369d5a4a3beace39e92ae ksmserver/shellpluginloader.h 6f13d493a800a7479711ef3549cfd9362a593778 ksmserver/shutdowndlg.cpp b4e59a387e5bf857db6314cf1b879e6a775e9f99 lookandfeelaccess/lookandfeelaccess.cpp 474e06d7b189fc368d1f9ba45426ea30392e2a71 shell/packageplugins/shell/shellpackage.h PRE-CREATION shell/packageplugins/shell/shellpackage.cpp PRE-CREATION shell/packageplugins/packages.cpp PRE-CREATION shell/packageplugins/shell/CMakeLists.txt PRE-CREATION shell/packageplugins/shell/Messages.sh PRE-CREATION shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop PRE-CREATION shell/packageplugins/wallpaper/CMakeLists.txt PRE-CREATION shell/packageplugins/wallpaper/plasma-packagestructure-wallpaper.desktop PRE-CREATION shell/packageplugins/wallpaper/wallpaper.h PRE-CREATION shell/packageplugins/wallpaper/wallpaper.cpp PRE-CREATION shell/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b shell/shellcorona.cpp 312003f6f1a27b1c624da17c310a148dff7131a3 dataengines/share/CMakeLists.txt 3d67b137f9a3e37453b8890d0d3c73e6469bae38 Diff: https://git.reviewboard.kde.org/r/119989/diff/ Testing --- Ran a full Plasma Desktop session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119989: PackageStructure plugins in plasma-workspaces
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119989/ --- (Updated Aug. 29, 2014, 12:19 p.m.) Review request for Plasma. Changes --- spiffed up the share engine's package structure cmake file. Repository: plasma-workspace Description --- This patchset introduces the use of PackageStructure plugins to plasma-workspace, allowing the removal of ShellPluginLoader everywhere. It also fixes some strange use of PackageStructure in the share DataEngine and updates that PackageStructure to use the JSON-based loading. With this changeset Plasma/Shell, Plasma/LookAndFeel and Plasma/Wallpaper are all plugins and accessible from everywhere that needs them via Plasma::PluginLoader. Diffs (updated) - shell/packageplugins/wallpaper/wallpaper.cpp PRE-CREATION shell/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b shell/shellcorona.cpp 312003f6f1a27b1c624da17c310a148dff7131a3 shell/CMakeLists.txt d67be9782de1faa9890bf85b8b2b517e15f12812 shell/main.cpp 04e1fd168df15bced40bfd84b965fb6f4905ded6 shell/osd.cpp 961c9ca3974337553bcefc1fc2c06222da9114e1 shell/packageplugins/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.h PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.cpp PRE-CREATION shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop PRE-CREATION shell/packageplugins/lookandfeel/CMakeLists.txt PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.h PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.cpp PRE-CREATION shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop PRE-CREATION shell/packageplugins/packages.h PRE-CREATION shell/packageplugins/packages.cpp PRE-CREATION shell/packageplugins/shell/CMakeLists.txt PRE-CREATION shell/packageplugins/shell/Messages.sh PRE-CREATION shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop PRE-CREATION shell/packageplugins/shell/shellpackage.h PRE-CREATION shell/packageplugins/shell/shellpackage.cpp PRE-CREATION shell/packageplugins/wallpaper/CMakeLists.txt PRE-CREATION shell/packageplugins/wallpaper/plasma-packagestructure-wallpaper.desktop PRE-CREATION shell/packageplugins/wallpaper/wallpaper.h PRE-CREATION dataengines/share/shareprovider.h c9159cdde6a858fbdca57ad7c5aa258028fd9ac3 dataengines/share/shareprovider.cpp fd1812fa1263cdf9df7d4340c681a63f8455ce07 dataengines/share/shareservice.h 5fb533d06fc74a52c33e0c8e1052ec93ffc4e11f dataengines/share/shareservice.cpp 8442b6634e5e55f8717b9684dd41839df8d3d677 krunner/main.cpp 408c5631a8007ac2617c7963cd83146dc4bbceeb krunner/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda krunner/view.cpp 0d986e845e3b9821ef39a874d431a087e2390e8a ksmserver/screenlocker/greeter/greeterapp.cpp 92e839091412585dddc369d5a4a3beace39e92ae ksmserver/shellpluginloader.h 6f13d493a800a7479711ef3549cfd9362a593778 ksmserver/shutdowndlg.cpp b4e59a387e5bf857db6314cf1b879e6a775e9f99 lookandfeelaccess/lookandfeelaccess.cpp 474e06d7b189fc368d1f9ba45426ea30392e2a71 lookandfeelaccess/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda plasma-windowed/main.cpp 4e9263aad9736b93dc00e7fef74db54b39456cb6 plasma-windowed/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b dataengines/share/packagestructure/CMakeLists.txt PRE-CREATION dataengines/share/plugin_share_package.cpp c4e2f23f7a65ddc67a94c60dffa3f71701a46b8b dataengines/share/share_package.h dataengines/share/share_package.cpp 13f41def3abd5ccf57b8745e3fd6956d10377a7a dataengines/share/CMakeLists.txt 3d67b137f9a3e37453b8890d0d3c73e6469bae38 dataengines/share/data/CMakeLists.txt e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 dataengines/share/data/plasma-packagestructure-share.desktop Diff: https://git.reviewboard.kde.org/r/119989/diff/ Testing --- Ran a full Plasma Desktop session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, 2 p.m., David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65481 --- On Aug. 29, 2014, 1:51 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 1:51 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119989: PackageStructure plugins in plasma-workspaces
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119989/#review65486 --- Ship it! rebased version looks good - Marco Martin On Aug. 29, 2014, 12:19 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119989/ --- (Updated Aug. 29, 2014, 12:19 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patchset introduces the use of PackageStructure plugins to plasma-workspace, allowing the removal of ShellPluginLoader everywhere. It also fixes some strange use of PackageStructure in the share DataEngine and updates that PackageStructure to use the JSON-based loading. With this changeset Plasma/Shell, Plasma/LookAndFeel and Plasma/Wallpaper are all plugins and accessible from everywhere that needs them via Plasma::PluginLoader. Diffs - shell/packageplugins/wallpaper/wallpaper.cpp PRE-CREATION shell/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b shell/shellcorona.cpp 312003f6f1a27b1c624da17c310a148dff7131a3 shell/CMakeLists.txt d67be9782de1faa9890bf85b8b2b517e15f12812 shell/main.cpp 04e1fd168df15bced40bfd84b965fb6f4905ded6 shell/osd.cpp 961c9ca3974337553bcefc1fc2c06222da9114e1 shell/packageplugins/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.h PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.cpp PRE-CREATION shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop PRE-CREATION shell/packageplugins/lookandfeel/CMakeLists.txt PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.h PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.cpp PRE-CREATION shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop PRE-CREATION shell/packageplugins/packages.h PRE-CREATION shell/packageplugins/packages.cpp PRE-CREATION shell/packageplugins/shell/CMakeLists.txt PRE-CREATION shell/packageplugins/shell/Messages.sh PRE-CREATION shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop PRE-CREATION shell/packageplugins/shell/shellpackage.h PRE-CREATION shell/packageplugins/shell/shellpackage.cpp PRE-CREATION shell/packageplugins/wallpaper/CMakeLists.txt PRE-CREATION shell/packageplugins/wallpaper/plasma-packagestructure-wallpaper.desktop PRE-CREATION shell/packageplugins/wallpaper/wallpaper.h PRE-CREATION dataengines/share/shareprovider.h c9159cdde6a858fbdca57ad7c5aa258028fd9ac3 dataengines/share/shareprovider.cpp fd1812fa1263cdf9df7d4340c681a63f8455ce07 dataengines/share/shareservice.h 5fb533d06fc74a52c33e0c8e1052ec93ffc4e11f dataengines/share/shareservice.cpp 8442b6634e5e55f8717b9684dd41839df8d3d677 krunner/main.cpp 408c5631a8007ac2617c7963cd83146dc4bbceeb krunner/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda krunner/view.cpp 0d986e845e3b9821ef39a874d431a087e2390e8a ksmserver/screenlocker/greeter/greeterapp.cpp 92e839091412585dddc369d5a4a3beace39e92ae ksmserver/shellpluginloader.h 6f13d493a800a7479711ef3549cfd9362a593778 ksmserver/shutdowndlg.cpp b4e59a387e5bf857db6314cf1b879e6a775e9f99 lookandfeelaccess/lookandfeelaccess.cpp 474e06d7b189fc368d1f9ba45426ea30392e2a71 lookandfeelaccess/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda plasma-windowed/main.cpp 4e9263aad9736b93dc00e7fef74db54b39456cb6 plasma-windowed/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b dataengines/share/packagestructure/CMakeLists.txt PRE-CREATION dataengines/share/plugin_share_package.cpp c4e2f23f7a65ddc67a94c60dffa3f71701a46b8b dataengines/share/share_package.h dataengines/share/share_package.cpp 13f41def3abd5ccf57b8745e3fd6956d10377a7a dataengines/share/CMakeLists.txt 3d67b137f9a3e37453b8890d0d3c73e6469bae38 dataengines/share/data/CMakeLists.txt e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 dataengines/share/data/plasma-packagestructure-share.desktop Diff: https://git.reviewboard.kde.org/r/119989/diff/ Testing --- Ran a full Plasma Desktop session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65481 --- On Aug. 29, 2014, 11:51 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 11:51 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, 2 p.m., David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? David Edmundson wrote: Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. if one doesn't recompile it should still work, shouldn't it? Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC (even if it means that we carry deprecated stuff for the time being, but after all that's the point of deprecation). - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65481 --- On Aug. 29, 2014, 1:51 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 1:51 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? David Edmundson wrote: Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. Martin Gräßlin wrote: if one doesn't recompile it should still work, shouldn't it? Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC (even if it means that we carry deprecated stuff for the time being, but after all that's the point of deprecation). Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? Not due to the issue you are responding to, no. The real issue for breakeage is the use of plasmaquick in Workspaces which violates the contract between Frameworks and Workspaces (due to being differnet products) by using a library in workspaces from framweorks that does not have a binary compatibility guarantee and which has no installed headers. I am at a loss as to how this could have shipped in this fashion. One possibility is to ship libplasmaquick as-is (with the PackageStructures duplicated and ShellPluginLoader) and simply remove its usage from Plasma Workspace (as already done in 119989), and then at some later point remove it from libplasmaquick and simply require a certain version # of Frameworks for Plasma Desktop. Requiring a minium v# of libraries would be a pretty normal state of affairs. If the intention is to allow Frameworks 5.2 to be used with Plasma Desktop 5.0, then that is probably the only realistic option. In which case the Plasma team ought to just install the headers for libplasmaquick and make it official. There is no point to requiring binary compatibility and trying to pretend a library is private. At which point there is a point in time where one can't compile plasma-workspace. An alternative is to state compatible versions of Frameworks with plasma-workspace. Either way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not functional. Currently relatively few people are using Plasma 5; I would urge the Plasma team to come up with a long-term solution before that changes. Carrying the impact of these decisions for 5+ years after Plasma 5 actually has users is .. well .. it's up to you. If it is decided not to merge this patchset, that's fine by me. I can probably re-work the related plasma-workspace patch set to use the older KService based plugin loading. It would just be nice to know *which* path (JSON or .desktop files) is being taken. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/#review65481 --- On Aug. 29, 2014, 11:51 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 11:51 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? David Edmundson wrote: Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. Martin Gräßlin wrote: if one doesn't recompile it should still work, shouldn't it? Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC (even if it means that we carry deprecated stuff for the time being, but after all that's the point of deprecation). Aaron J. Seigo wrote: Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? Not due to the issue you are responding to, no. The real issue for breakeage is the use of plasmaquick in Workspaces which violates the contract between Frameworks and Workspaces (due to being differnet products) by using a library in workspaces from framweorks that does not have a binary compatibility guarantee and which has no installed headers. I am at a loss as to how this could have shipped in this fashion. One possibility is to ship libplasmaquick as-is (with the PackageStructures duplicated and ShellPluginLoader) and simply remove its usage from Plasma Workspace (as already done in 119989), and then at some later point remove it from libplasmaquick and simply require a certain version # of Frameworks for Plasma Desktop. Requiring a minium v# of libraries would be a pretty normal state of affairs. If the intention is to allow Frameworks 5.2 to be used with Plasma Desktop 5.0, then that is probably the only realistic option. In which case the Plasma team ought to just install the headers for libplasmaquick and make it official. There is no point to requiring binary compatibility and trying to pretend a library is private. At which point there is a point in time where one can't compile plasma-workspace. An alternative is to state compatible versions of Frameworks with plasma-workspace. Either way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not functional. Currently relatively few people are using Plasma 5; I would urge the Plasma team to come up with a long-term solution before that changes. Carrying the impact of these decisions for 5+ years after Plasma 5 actually has users is .. well .. it's up to you. If it is decided not to merge this patchset, that's fine by me. I can probably re-work the related plasma-workspace patch set to use the older KService based plugin loading. It would just be nice to know *which* path (JSON or .desktop files) is being taken. Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC This will ensure things still compile, but the result will be plugins that do not get loaded. If the old defines are desired to be kept, then PluginLoader should probably be extended to try to load with KPluginTrader first and then if that fails try KServiceTypeTrader. Or vice versa (KServiceTypeTrader first and then KPluginTrader). Which is tried first should reflect the long-term plan for plugin loading as that will be the common
Review Request 119990: Fix libraries and includes to follow the KF5 naming scheme
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119990/ --- Review request for Plasma. Repository: libksysguard Description --- Since libksysguard probably aims to be a framework, the libraries should have respective names and includes should be installed to KF5_INCLUE_INSTALL_DIR. Solves conflicts with KDE 4. Diffs - ksgrd/CMakeLists.txt 64ad24a lsofui/CMakeLists.txt 2b0c8ac processcore/CMakeLists.txt 31eee10 processui/CMakeLists.txt 150e198 signalplotter/CMakeLists.txt 67aa8bb Diff: https://git.reviewboard.kde.org/r/119990/diff/ Testing --- Builds, installs, libraries are called libKF5*.so, includes in /usr/include/KF5/KSysGuard/ Thanks, Dan Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? David Edmundson wrote: Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. Martin Gräßlin wrote: if one doesn't recompile it should still work, shouldn't it? Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC (even if it means that we carry deprecated stuff for the time being, but after all that's the point of deprecation). Aaron J. Seigo wrote: Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? Not due to the issue you are responding to, no. The real issue for breakeage is the use of plasmaquick in Workspaces which violates the contract between Frameworks and Workspaces (due to being differnet products) by using a library in workspaces from framweorks that does not have a binary compatibility guarantee and which has no installed headers. I am at a loss as to how this could have shipped in this fashion. One possibility is to ship libplasmaquick as-is (with the PackageStructures duplicated and ShellPluginLoader) and simply remove its usage from Plasma Workspace (as already done in 119989), and then at some later point remove it from libplasmaquick and simply require a certain version # of Frameworks for Plasma Desktop. Requiring a minium v# of libraries would be a pretty normal state of affairs. If the intention is to allow Frameworks 5.2 to be used with Plasma Desktop 5.0, then that is probably the only realistic option. In which case the Plasma team ought to just install the headers for libplasmaquick and make it official. There is no point to requiring binary compatibility and trying to pretend a library is private. At which point there is a point in time where one can't compile plasma-workspace. An alternative is to state compatible versions of Frameworks with plasma-workspace. Either way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not functional. Currently relatively few people are using Plasma 5; I would urge the Plasma team to come up with a long-term solution before that changes. Carrying the impact of these decisions for 5+ years after Plasma 5 actually has users is .. well .. it's up to you. If it is decided not to merge this patchset, that's fine by me. I can probably re-work the related plasma-workspace patch set to use the older KService based plugin loading. It would just be nice to know *which* path (JSON or .desktop files) is being taken. Aaron J. Seigo wrote: Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC This will ensure things still compile, but the result will be plugins that do not get loaded. If the old defines are desired to be kept, then PluginLoader should probably be extended to try to load with KPluginTrader first and then if that fails try KServiceTypeTrader. Or vice versa (KServiceTypeTrader first and then KPluginTrader). Which is tried first should reflect the long-term plan for
Review Request 119992: PackageStructure plugin loading and tidy up of DataEngien plugin loading
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119992/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch removes dead code (ContainmentPackage), clean up DataEngine plugin loading and updates PackageStructure plugin loading. Open question: which plugin loading mechanism is to be used: a) KServiceTypeTrader b) KPluginTrader c) KPlugintTrader with a KServiceTypeTrade fallback d) KServiceTypeTrader with a KPluginTrader fallback DataEngine is currently (b), complete with a #define in the header that won't work as expected. In this patch PackageStructure is moved to (b) as well. (There is an open RR for a correponding patch set in plasma-workspace). Everything else seems to use (a). Some plugins are not used in Plasma 5 due to changes with QML, and I guess that some of this confusion is due to the decreased use of some of these plugins. A decision needs to be made, however about what they should be now and in the future. Diffs - src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 Diff: https://git.reviewboard.kde.org/r/119992/diff/ Testing --- Ran a Plasma Desktop 5 session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119988/ --- (Updated Aug. 29, 2014, 2:20 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch set does the following: * tidy up the data engine plugin loading code * make PackageStructure plugins use the json method as with DataEngines * remove ShellPackage; it moves to live with plasmashell (review #119989) The goal here is to get rid of the plasmaquick library as much as possible. It was unnecessary in the first place since PackageStructure supports plugins. The only potentially controversial change here is to move PackageStructure to use the json-based plugin loading. That seems to be the more modern approach, but plugin loading in libplasma is currently a mix of the old and the new. As PackageStructure changed API in plasma-framework, meaning any existing plugins from 4.x would need updating anyways, this seems a safe enough change to make as it should impact exactly zero plugins out there currently. Diffs - src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasmaquick/CMakeLists.txt 1ed7c67efcba0e6dbef1ff929b176090786503de src/plasmaquick/private/packages.h 7498832d0537611903c13e544db6486bab163dd3 src/plasmaquick/private/packages.cpp 52758482230d271712e4bb3b6d33f8fdeaa848a8 src/plasmaquick/shellpluginloader.h 6c56e5f7b269c3af7587a58cbe104468a2c679c4 src/plasmaquick/shellpluginloader.cpp 2824760e6f64a694bd14b46d2f80151304e3e4d3 src/plasma/dataengine.h d87a6f8361c892a249374a5c9da7e84836195156 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 Diff: https://git.reviewboard.kde.org/r/119988/diff/ Testing --- Ran a full Plasma Desktop session. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119992: PackageStructure plugin loading and tidy up of DataEngien plugin loading
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119992/#review65507 --- Ship it! this having both defines should make old users build without problems. +1 for me.. - Marco Martin On Aug. 29, 2014, 2:20 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119992/ --- (Updated Aug. 29, 2014, 2:20 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch removes dead code (ContainmentPackage), clean up DataEngine plugin loading and updates PackageStructure plugin loading. Open question: which plugin loading mechanism is to be used: a) KServiceTypeTrader b) KPluginTrader c) KPlugintTrader with a KServiceTypeTrade fallback d) KServiceTypeTrader with a KPluginTrader fallback DataEngine is currently (b), complete with a #define in the header that won't work as expected. In this patch PackageStructure is moved to (b) as well. (There is an open RR for a correponding patch set in plasma-workspace). Everything else seems to use (a). Some plugins are not used in Plasma 5 due to changes with QML, and I guess that some of this confusion is due to the decreased use of some of these plugins. A decision needs to be made, however about what they should be now and in the future. Diffs - src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 Diff: https://git.reviewboard.kde.org/r/119992/diff/ Testing --- Ran a Plasma Desktop 5 session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119992: PackageStructure plugin loading and tidy up of DataEngien plugin loading
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119992/#review65508 --- Ship it! and +1 me. Thanks. - David Edmundson On Aug. 29, 2014, 2:20 p.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119992/ --- (Updated Aug. 29, 2014, 2:20 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch removes dead code (ContainmentPackage), clean up DataEngine plugin loading and updates PackageStructure plugin loading. Open question: which plugin loading mechanism is to be used: a) KServiceTypeTrader b) KPluginTrader c) KPlugintTrader with a KServiceTypeTrade fallback d) KServiceTypeTrader with a KPluginTrader fallback DataEngine is currently (b), complete with a #define in the header that won't work as expected. In this patch PackageStructure is moved to (b) as well. (There is an open RR for a correponding patch set in plasma-workspace). Everything else seems to use (a). Some plugins are not used in Plasma 5 due to changes with QML, and I guess that some of this confusion is due to the decreased use of some of these plugins. A decision needs to be made, however about what they should be now and in the future. Diffs - src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 Diff: https://git.reviewboard.kde.org/r/119992/diff/ Testing --- Ran a Plasma Desktop 5 session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? David Edmundson wrote: Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. Martin Gräßlin wrote: if one doesn't recompile it should still work, shouldn't it? Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC (even if it means that we carry deprecated stuff for the time being, but after all that's the point of deprecation). Aaron J. Seigo wrote: Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? Not due to the issue you are responding to, no. The real issue for breakeage is the use of plasmaquick in Workspaces which violates the contract between Frameworks and Workspaces (due to being differnet products) by using a library in workspaces from framweorks that does not have a binary compatibility guarantee and which has no installed headers. I am at a loss as to how this could have shipped in this fashion. One possibility is to ship libplasmaquick as-is (with the PackageStructures duplicated and ShellPluginLoader) and simply remove its usage from Plasma Workspace (as already done in 119989), and then at some later point remove it from libplasmaquick and simply require a certain version # of Frameworks for Plasma Desktop. Requiring a minium v# of libraries would be a pretty normal state of affairs. If the intention is to allow Frameworks 5.2 to be used with Plasma Desktop 5.0, then that is probably the only realistic option. In which case the Plasma team ought to just install the headers for libplasmaquick and make it official. There is no point to requiring binary compatibility and trying to pretend a library is private. At which point there is a point in time where one can't compile plasma-workspace. An alternative is to state compatible versions of Frameworks with plasma-workspace. Either way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not functional. Currently relatively few people are using Plasma 5; I would urge the Plasma team to come up with a long-term solution before that changes. Carrying the impact of these decisions for 5+ years after Plasma 5 actually has users is .. well .. it's up to you. If it is decided not to merge this patchset, that's fine by me. I can probably re-work the related plasma-workspace patch set to use the older KService based plugin loading. It would just be nice to know *which* path (JSON or .desktop files) is being taken. Aaron J. Seigo wrote: Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC This will ensure things still compile, but the result will be plugins that do not get loaded. If the old defines are desired to be kept, then PluginLoader should probably be extended to try to load with KPluginTrader first and then if that fails try KServiceTypeTrader. Or vice versa (KServiceTypeTrader first and then KPluginTrader). Which is tried first should reflect the long-term plan for
Re: Review Request 119988: Package structure cleanups
On Aug. 29, 2014, noon, David Edmundson wrote: src/plasma/packagestructure.h, line 99 https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99 would removing a #define count as a SIC? Aaron J. Seigo wrote: Yes, but I don't think it maters for two reasons: 1) DataEngine also had both forms but only one actually currently works; so it is on the face of it *broken* .. removing that is the same as this change at the end of the day 2) There are no Plasma 5 PackageStructure plugins out there except the share dataengine in plasma-workspace (which itself was done in a very odd manner) Neither reason is particularly *good* from the perspective of strict policy adherence, but they demonstrate that it is a harmless violation. May as well get it right imho. I'd add a third consideration as well: It is quite evident that plasma-framework was release before it was ready. The plugin loading is entirely inconsistent with DataEngines using JSON and the Qt5 plugin loading an the rest of the plugins not. Some of the plugins are obviously not being used at all due to changes brought about with QML2 and that probably contributed to the lack of attention. However, PluginLoader quite obviously went through a partial refactoring that was never completed. It's a little brash to commit to source and binary compatibility when things are in that shape. Hrvoje Senjan wrote: Yes, but I don't think it maters for two reasons Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? David Edmundson wrote: Whilst I agree that the frameworks situation sucks, I'm not sure we have a choice. Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in time where one can't compile plasma-workspace. We could make it go via a no-op that does nothing. Martin Gräßlin wrote: if one doesn't recompile it should still work, shouldn't it? Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC (even if it means that we carry deprecated stuff for the time being, but after all that's the point of deprecation). Aaron J. Seigo wrote: Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)? Not due to the issue you are responding to, no. The real issue for breakeage is the use of plasmaquick in Workspaces which violates the contract between Frameworks and Workspaces (due to being differnet products) by using a library in workspaces from framweorks that does not have a binary compatibility guarantee and which has no installed headers. I am at a loss as to how this could have shipped in this fashion. One possibility is to ship libplasmaquick as-is (with the PackageStructures duplicated and ShellPluginLoader) and simply remove its usage from Plasma Workspace (as already done in 119989), and then at some later point remove it from libplasmaquick and simply require a certain version # of Frameworks for Plasma Desktop. Requiring a minium v# of libraries would be a pretty normal state of affairs. If the intention is to allow Frameworks 5.2 to be used with Plasma Desktop 5.0, then that is probably the only realistic option. In which case the Plasma team ought to just install the headers for libplasmaquick and make it official. There is no point to requiring binary compatibility and trying to pretend a library is private. At which point there is a point in time where one can't compile plasma-workspace. An alternative is to state compatible versions of Frameworks with plasma-workspace. Either way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not functional. Currently relatively few people are using Plasma 5; I would urge the Plasma team to come up with a long-term solution before that changes. Carrying the impact of these decisions for 5+ years after Plasma 5 actually has users is .. well .. it's up to you. If it is decided not to merge this patchset, that's fine by me. I can probably re-work the related plasma-workspace patch set to use the older KService based plugin loading. It would just be nice to know *which* path (JSON or .desktop files) is being taken. Aaron J. Seigo wrote: Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block to keep SIC This will ensure things still compile, but the result will be plugins that do not get loaded. If the old defines are desired to be kept, then PluginLoader should probably be extended to try to load with KPluginTrader first and then if that fails try KServiceTypeTrader. Or vice versa (KServiceTypeTrader first and then KPluginTrader). Which is tried first should reflect the long-term plan for
Re: Review Request 119992: PackageStructure plugin loading and tidy up of DataEngien plugin loading
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119992/ --- (Updated Aug. 29, 2014, 3:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- This patch removes dead code (ContainmentPackage), clean up DataEngine plugin loading and updates PackageStructure plugin loading. Open question: which plugin loading mechanism is to be used: a) KServiceTypeTrader b) KPluginTrader c) KPlugintTrader with a KServiceTypeTrade fallback d) KServiceTypeTrader with a KPluginTrader fallback DataEngine is currently (b), complete with a #define in the header that won't work as expected. In this patch PackageStructure is moved to (b) as well. (There is an open RR for a correponding patch set in plasma-workspace). Everything else seems to use (a). Some plugins are not used in Plasma 5 due to changes with QML, and I guess that some of this confusion is due to the decreased use of some of these plugins. A decision needs to be made, however about what they should be now and in the future. Diffs - src/plasma/pluginloader.cpp d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df src/plasma/private/packages.cpp 5eb6f0021392257634dfd958c940b2945989e48b src/plasma/private/packages_p.h 0833a4ed1b5704efffccade5e52589878e8b4957 src/plasma/package.cpp 6ad332167bb83c2f794f9f5d059e9f369ad33841 src/plasma/packagestructure.h fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3 Diff: https://git.reviewboard.kde.org/r/119992/diff/ Testing --- Ran a Plasma Desktop 5 session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119989: PackageStructure plugins in plasma-workspaces
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119989/ --- (Updated Aug. 29, 2014, 3:26 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- This patchset introduces the use of PackageStructure plugins to plasma-workspace, allowing the removal of ShellPluginLoader everywhere. It also fixes some strange use of PackageStructure in the share DataEngine and updates that PackageStructure to use the JSON-based loading. With this changeset Plasma/Shell, Plasma/LookAndFeel and Plasma/Wallpaper are all plugins and accessible from everywhere that needs them via Plasma::PluginLoader. Diffs - shell/packageplugins/wallpaper/wallpaper.cpp PRE-CREATION shell/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b shell/shellcorona.cpp 312003f6f1a27b1c624da17c310a148dff7131a3 shell/CMakeLists.txt d67be9782de1faa9890bf85b8b2b517e15f12812 shell/main.cpp 04e1fd168df15bced40bfd84b965fb6f4905ded6 shell/osd.cpp 961c9ca3974337553bcefc1fc2c06222da9114e1 shell/packageplugins/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/CMakeLists.txt PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.h PRE-CREATION shell/packageplugins/layouttemplate/layouttemplate.cpp PRE-CREATION shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop PRE-CREATION shell/packageplugins/lookandfeel/CMakeLists.txt PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.h PRE-CREATION shell/packageplugins/lookandfeel/lookandfeel.cpp PRE-CREATION shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop PRE-CREATION shell/packageplugins/packages.h PRE-CREATION shell/packageplugins/packages.cpp PRE-CREATION shell/packageplugins/shell/CMakeLists.txt PRE-CREATION shell/packageplugins/shell/Messages.sh PRE-CREATION shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop PRE-CREATION shell/packageplugins/shell/shellpackage.h PRE-CREATION shell/packageplugins/shell/shellpackage.cpp PRE-CREATION shell/packageplugins/wallpaper/CMakeLists.txt PRE-CREATION shell/packageplugins/wallpaper/plasma-packagestructure-wallpaper.desktop PRE-CREATION shell/packageplugins/wallpaper/wallpaper.h PRE-CREATION dataengines/share/shareprovider.h c9159cdde6a858fbdca57ad7c5aa258028fd9ac3 dataengines/share/shareprovider.cpp fd1812fa1263cdf9df7d4340c681a63f8455ce07 dataengines/share/shareservice.h 5fb533d06fc74a52c33e0c8e1052ec93ffc4e11f dataengines/share/shareservice.cpp 8442b6634e5e55f8717b9684dd41839df8d3d677 krunner/main.cpp 408c5631a8007ac2617c7963cd83146dc4bbceeb krunner/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda krunner/view.cpp 0d986e845e3b9821ef39a874d431a087e2390e8a ksmserver/screenlocker/greeter/greeterapp.cpp 92e839091412585dddc369d5a4a3beace39e92ae ksmserver/shellpluginloader.h 6f13d493a800a7479711ef3549cfd9362a593778 ksmserver/shutdowndlg.cpp b4e59a387e5bf857db6314cf1b879e6a775e9f99 lookandfeelaccess/lookandfeelaccess.cpp 474e06d7b189fc368d1f9ba45426ea30392e2a71 lookandfeelaccess/shellpluginloader.h 9c0f62412eac4d1ad03c681325852d9efe25ccda plasma-windowed/main.cpp 4e9263aad9736b93dc00e7fef74db54b39456cb6 plasma-windowed/plasmaquick/shellpluginloader.h ea0755e4abe841e33777d89cb12a5e689161e51b dataengines/share/packagestructure/CMakeLists.txt PRE-CREATION dataengines/share/plugin_share_package.cpp c4e2f23f7a65ddc67a94c60dffa3f71701a46b8b dataengines/share/share_package.h dataengines/share/share_package.cpp 13f41def3abd5ccf57b8745e3fd6956d10377a7a dataengines/share/CMakeLists.txt 3d67b137f9a3e37453b8890d0d3c73e6469bae38 dataengines/share/data/CMakeLists.txt e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 dataengines/share/data/plasma-packagestructure-share.desktop Diff: https://git.reviewboard.kde.org/r/119989/diff/ Testing --- Ran a full Plasma Desktop session with these changes. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Build failed in Jenkins: plasma-workspace_master_qt5 #797
See http://build.kde.org/job/plasma-workspace_master_qt5/797/changes Changes: [aseigo] add the package plugins to the build [aseigo] put the shell package into a plugin [aseigo] fix use of the package plugin [aseigo] package-packagestructure [aseigo] relative paths are supported [aseigo] Plasma/LayoutTemplate, Plasma/LookAndFeel Plasma/Wallpaper PackageStructure plugins [aseigo] ShellPluginLoader is no longer necessary [aseigo] remove all the (often random) uses of ShellPluginLoader [aseigo] build file [aseigo] need to include plasma as the root [aseigo] shuffle srcs into the correct cmake file -- [...truncated 1788 lines...] [ 22%] Built target kdeinit_kuiserver5_automoc [ 22%] [ 23%] [ 23%] Building CXX object libkworkspace/CMakeFiles/kworkspace.dir/kworkspace.cpp.o Building CXX object components/shellprivate/CMakeFiles/plasmashellprivateplugin.dir/widgetexplorer/kcategorizeditemsviewmodels.cpp.o Building CXX object plasma-windowed/CMakeFiles/plasmawindowed.dir/plasmawindowedcorona.cpp.o Scanning dependencies of target taskmanager Generating moc_kglobalacceld.cpp Generating moc_kglobalaccel_x11.cpp [ 23%] Built target kdeinit_kglobalaccel5_automoc [ 23%] [ 23%] Generating deviceserviceaction.moc Generating soliduiserver.moc Generating moc_deviceactionsdialog.cpp Generating moc_soliduiserver.cpp Building CXX object libtaskmanager/CMakeFiles/taskmanager.dir/abstractgroupableitem.cpp.o [ 23%] Scanning dependencies of target kded_appmenu Building CXX object libkworkspace/CMakeFiles/kworkspace.dir/ksmserver_interface.cpp.o Built target kded_soliduiserver_automoc [ 23%] [ 23%] Generating krunner_interface.cpp, krunner_interface.h Building CXX object appmenu/CMakeFiles/kded_appmenu.dir/appmenu.cpp.o [ 23%] Generating plasmashelladaptor.cpp, plasmashelladaptor.h [ 23%] Generating plasmashelladaptor.moc [ 23%] Generating krunner_interface.moc Scanning dependencies of target plasmashell [ 23%] Building CXX object shell/CMakeFiles/plasmashell.dir/activity.cpp.o [ 23%] Building CXX object plasma-windowed/CMakeFiles/plasmawindowed.dir/plasmawindowedview.cpp.o [ 23%] Generating moc_aboutbugreportingdialog.cpp Generating moc_applicationdetailsexamples.cpp Generating moc_backtracegenerator.cpp Generating moc_backtraceratingwidget.cpp Generating moc_backtracewidget.cpp Generating moc_bugzillalib.cpp Generating moc_duplicatefinderjob.cpp Generating moc_parsebugbacktraces.cpp Generating moc_productmapping.cpp Generating moc_reportassistantdialog.cpp Generating moc_reportassistantpage.cpp Generating moc_reportassistantpages_base.cpp Generating moc_reportassistantpages_bugzilla.cpp Generating moc_reportassistantpages_bugzilla_duplicates.cpp Generating moc_reportinterface.cpp Generating moc_crashedapplication.cpp Generating moc_debuggerlaunchers.cpp Generating moc_debuggermanager.cpp Generating moc_debugpackageinstaller.cpp Generating moc_detachedprocessmonitor.cpp Generating moc_drkonqibackends.cpp Generating moc_drkonqidialog.cpp Generating moc_statuswidget.cpp Generating moc_systeminformation.cpp [ 23%] Built target drkonqi_automoc Building CXX object libkworkspace/CMakeFiles/kworkspace.dir/kwin_interface.cpp.o Scanning dependencies of target plasma_packagestructure_layoutemplate [ 24%] Building CXX object shell/packageplugins/layouttemplate/CMakeFiles/plasma_packagestructure_layoutemplate.dir/layouttemplate.cpp.o [ 24%] Building CXX object libtaskmanager/CMakeFiles/taskmanager.dir/abstractgroupingstrategy.cpp.o [ 24%] Building CXX object libkworkspace/CMakeFiles/kworkspace.dir/kworkspace_automoc.cpp.o [ 25%] Building CXX object plasma-windowed/CMakeFiles/plasmawindowed.dir/main.cpp.o http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp: In destructor ‘virtual AppMenuModule::~AppMenuModule()’: http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp:92:16: warning: possible problem detected in invocation of delete operator: [enabled by default] delete m_menubar; ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp:92:16: warning: invalid use of incomplete type ‘class TopMenuBar’ [enabled by default] In file included from http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp:26:0: http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.h:36:7: warning: forward declaration of ‘class TopMenuBar’ [enabled by default] class TopMenuBar; ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp:92:16: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined delete m_menubar; ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp: In member function ‘void AppMenuModule::reconfigure()’: http://build.kde.org/job/plasma-workspace_master_qt5/ws/appmenu/appmenu.cpp:296:16: warning:
Review Request 119993: Port KAuth actions in libksysguard
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119993/ --- Review request for Plasma. Repository: libksysguard Description --- that was one (vital imho ;-) feature missing compared to 4.x Diffs - processui/ksysguardprocesslist.cpp 1651a0a processcore/CMakeLists.txt 31eee10 processcore/helper.cpp 6c1f570 processcore/processes_linux_p.cpp 65b8dfd Diff: https://git.reviewboard.kde.org/r/119993/diff/ Testing --- ioscheduler, cpuscheduler, sendsignal, renice actions all work. Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119993: Port KAuth actions in libksysguard
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119993/#review65524 --- Ship it! Ship It! - Aleix Pol Gonzalez On Aug. 29, 2014, 4:12 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119993/ --- (Updated Aug. 29, 2014, 4:12 p.m.) Review request for Plasma. Repository: libksysguard Description --- that was one (vital imho ;-) feature missing compared to 4.x Diffs - processui/ksysguardprocesslist.cpp 1651a0a processcore/CMakeLists.txt 31eee10 processcore/helper.cpp 6c1f570 processcore/processes_linux_p.cpp 65b8dfd Diff: https://git.reviewboard.kde.org/r/119993/diff/ Testing --- ioscheduler, cpuscheduler, sendsignal, renice actions all work. Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119983: Use font metrics to scale icons for high dpi outputs
On Aug. 29, 2014, 10:33 a.m., David Edmundson wrote: I'm on a standard pleb monitor, I get: $ ./dpitest dpitest(8664)/(default) Plasma::DPITest::runMain: DPI test runs: dpitest(8664)/(default) Plasma::DPITest::runMain: font.pixelSize: -1 dpitest(8664)/(default) Plasma::DPITest::runMain: font.pointSize: 9 dpitest(8664)/(default) Plasma::DPITest::runMain: devicePixelRatio: 0.963947 dpitest(8664)/(default) Plasma::DPITest::runMain: pointSize * devicePixelRatio: 8.67552 dpitest(8664)/(default) Plasma::DPITest::runMain: dpi: 92.5389 dpitest(8664)/(default) Plasma::DPITest::runMain: gridUnit: 14 dpitest(8664)/(default) Plasma::DPITest::runMain: gridUnit / pointSize : 1.6 I should have a ratio of ~1 I think, but it does seem to look OK. I'll pester vishesh to run it too. actaully kickoff is a bit big: http://imgur.com/Kg8BXcI - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/#review65473 --- On Aug. 28, 2014, 11:03 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/ --- (Updated Aug. 28, 2014, 11:03 p.m.) Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Vishesh Handa. Bugs: 337712 and 338308 http://bugs.kde.org/show_bug.cgi?id=337712 http://bugs.kde.org/show_bug.cgi?id=338308 Repository: plasma-framework Description --- Use font metrics to scale icons for high dpi outputs QScreen, through EDID reports bogus values for physicalDotsPerInch*(). This leads to oversized icons on monitors with bogus edid information. This patch changes the ratio underlying to the icon sizing for displays with a DPI 96 * 1.5 to use the ratio between the font as rendered (its effective pixelSize, essentially) to scale the icon sizes up. As we rely on proper font metrics throughout already, this should bring sizing in line with the font, which is something that makes sense as it means we're sharing the underlying mechanism (font metrics) for sizing in different areas. The downside of this patch is that we're essentially working around an issue that should be fixed in the hardware, the monitor's edid. Unrealistic. print dpi / sizing in dpitest Print out some useful information to deduce dpi and pixel sizing. David, and Kai Uwe, Vishesh (since I know you have a high DPI displays), could you run this patch for a bit and check if it works for you, too? I've pushed it to plasma-framework[sebas/dpi] for your git convenience. Diffs - src/declarativeimports/core/units.h ba481781a04a54cb77f99048d3d400fdae617b38 src/declarativeimports/core/units.cpp 56c0b55427c128beff5f8d18c37847a435f194c0 tests/dpi/dpitest.cpp c3d2c3e6821fd79fc8b5ed0b3559a5870f88aa36 Diff: https://git.reviewboard.kde.org/r/119983/diff/ Testing --- Ran Plasma Desktop, no apparent problems (on this hardware, which worked, anyway). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
