[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request 119988: Package structure cleanups
From: "Marco Martin" <notmart () gmail ! com>
Date: 2014-08-29 15:25:48
Message-ID: 20140829152548.11205.80166 () probe ! kde ! org
[Download RAW message or body]
--===============1345080764530757542==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> 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 plugin \
> loading as that will be the common path (and so should be as fast as reasonably possible).
> Note that currently DataEngine is broken for plugins compiled with the old define, so this is an issue \
> that needs addressing with or without this patch set.
> Marco Martin wrote:
> "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."
> I am not sure about the current state, maybe ConfigView should be a bit different, but I'm fine with \
> officially release libpolasmaquick with at lease View and Dialog. Maybe configview and its models, but \
> not i'm not completely sure about it since i don't like them too much to be there, but they are \
> used/needed, may be moved to a similar thing in workspace, or made more generic by making them not \
> views but to create windows from QML
> Aaron J. Seigo wrote:
> That's kind of the problem, though: you may not be comfortable with the library, but you've (the entire \
> team) already committed to binary and source compatibility by putting the library in a different \
> product (Frameworks).
> However it goes, my current work project's requirements dictate the need to pick libplasmaquick out of \
> plasma-workspace and I will continue to work on that so that it eventually becomes a moot point.
> Since this is an issues which the Plasma team apparently has no clear path in mind, let's just assume \
> for the same of argument that libplasmaquick remains exactly as it is in plasma-framework. What I \
> actually need your input on is what plugin loading mechanism is to be used:
> a) KServiceTypeTrader
> b) KPluginTrader
> c) KPlugintTrader with a KServiceTypeTrade fallback
> d) KServiceTypeTrader with a KPluginTrader fallback
>
> In fact, I'll open a new review request that reflects that more clearly.
>
> David Edmundson wrote:
> > Either way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not \
> > functional.
>
> There's some crossed communication I think. I'm not asking for anyone to resolve it, I'm wanting it to \
> not break things.
> I'm happy with your changes. If what we have doesn't work now, it can proceed to not work, and we can \
> add the additional new thing that fixes it. That's all great.
> What concerns me is the idea that it would stop the rest of plasma-workspace stable compiling for a \
> whole month. That would have most packagers screaming at us.
> We just need to keep the old #define till frameworks 5.4
>
> > The real issue for breakeage is the use of plasmaquick
>
> That's a completely different topic and we should try not to get distracted by it.
>
> Marco Martin wrote:
> "We just need to keep the old #define till frameworks 5.4"
> do you think it may be removed after 5.4 or better leaving it for the time being?
> dataengine already has both, so i would put as a policy
> c) KPlugintTrader with a KServiceTypeTrade fallback
> K_EXPORT_PLASMA_DATAENGINE K_EXPORT_PLASMA_PACKAGE etc, may be wrapped in an #idef no_deprecated
>
> David Edmundson wrote:
> Once we have Plasma 5.1.0 out, I think it will be OK to sneakily remove it.
> Your call.
if we do it, it may be worth to do in one go for dataengines, applets appletscripts as well
- Marco
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119988/#review65481
-----------------------------------------------------------
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/119988/
> -----------------------------------------------------------
>
> (Updated Aug. 29, 2014, 2:20 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
>
>
--===============1345080764530757542==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; \
border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/119988/">https://git.reviewboard.kde.org/r/119988/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On August 29th, 2014, noon UTC, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: \
collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: \
4px 8px; text-align: left;"> <a \
href="https://git.reviewboard.kde.org/r/119988/diff/1/?file=308188#file308188line99" style="color: black; \
font-weight: bold; text-decoration: underline;">src/plasma/packagestructure.h</a> <span \
style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">private:</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" align="right"><font \
size="2">98</font></th> <td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; \
margin: 0; "><span class="cp">#define K_EXPORT_PLASMA_PACKAGE(libname, classname) \</span></pre></td> \
<th bgcolor="#e9eaa8" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" \
align="right"><font size="2">99</font></th> <td bgcolor="#fdfebc" width="50%"><pre style="font-size: \
8pt; line-height: 140%; margin: 0; "></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">would removing a #define count as a SIC?</p></pre> </blockquote>
<p>On August 29th, 2014, 12:12 p.m. UTC, <b>Aaron J. Seigo</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Yes, but I don't think it maters for two reasons:</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">1) DataEngine also had \
both forms but only one actually currently works; so it is on the face of it <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">broken</em> .. removing \
that is the same as this change at the end of the day<br style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;" /> 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)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Neither reason is particularly <em style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;">good</em> from the perspective of strict policy adherence, \
but they demonstrate that it is a harmless violation. May as well get it right imho.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre> </blockquote>
<p>On August 29th, 2014, 12:21 p.m. UTC, <b>Hrvoje Senjan</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 \
1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, but \
I don't think it maters for two reasons</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Can \
users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out (if this patch goes in)?</p></pre> \
</blockquote>
<p>On August 29th, 2014, 12:25 p.m. UTC, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Whilst I agree that the frameworks situation sucks, I'm not sure we have a \
choice.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Frameworks 5.2 releases independently of plasma-workspace. At which point there is a point in \
time where one can't compile plasma-workspace.<br style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;" /> We could make it go via a no-op that does \
nothing.</p></pre> </blockquote>
<p>On August 29th, 2014, 12:32 p.m. UTC, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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).</p></pre> \
</blockquote>
<p>On August 29th, 2014, 12:46 p.m. UTC, <b>Aaron J. Seigo</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">"Can users of Plasma 5.0.x can expect a broken desktop once KF5 5.2 is out \
(if this patch goes in)?"</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Not due to the issue you are responding to, no.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">"At which point there is a point in time where one can't \
compile plasma-workspace."</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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 \
<em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">which</em> path (JSON or .desktop files) is being taken.</p></pre> </blockquote>
<p>On August 29th, 2014, 12:50 p.m. UTC, <b>Aaron J. Seigo</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">"Otherwise I'd suggest to wrap the define in a ifndef NO_DEPRECATED block \
to keep SIC"</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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 path (and so should be as fast as reasonably possible).</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Note that currently \
DataEngine is broken for plugins compiled with the old define, so this is an issue that needs addressing \
with or without this patch set.</p></pre> </blockquote>
<p>On August 29th, 2014, 1:04 p.m. UTC, <b>Marco Martin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">"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."</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I am not sure about the current state, maybe ConfigView should be a bit \
different, but I'm fine with officially release libpolasmaquick with at lease View and Dialog.<br \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> Maybe \
configview and its models, but not i'm not completely sure about it since i don't like them too much to \
be there, but they are used/needed, may be moved to a similar thing in workspace, or made more generic by \
making them not views but to create windows from QML</p></pre> </blockquote>
<p>On August 29th, 2014, 2:10 p.m. UTC, <b>Aaron J. Seigo</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">That's kind of the problem, though: you may not be comfortable with the \
library, but you've (the entire team) already committed to binary and source compatibility by putting the \
library in a different product (Frameworks).</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">However it goes, my current work project's requirements \
dictate the need to pick libplasmaquick out of plasma-workspace and I will continue to work on that so \
that it eventually becomes a moot point.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Since this is an issues which the Plasma team apparently \
has no clear path in mind, let's just assume for the same of argument that libplasmaquick remains exactly \
as it is in plasma-framework. What I actually need your input on is what plugin loading mechanism is to \
be used:</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">a) KServiceTypeTrader <br style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;" /> b) KPluginTrader<br style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;" /> c) KPlugintTrader with a KServiceTypeTrade fallback<br \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> d) \
KServiceTypeTrader with a KPluginTrader fallback</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">In fact, I'll open a new review request that reflects that \
more clearly.</p></pre> </blockquote>
<p>On August 29th, 2014, 2:22 p.m. UTC, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 \
1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Either \
way, it doesn't resolve the DataEngine situation where it may be SC but certainly is not functional.</p> \
</blockquote> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">There's some crossed communication I think. I'm not asking for anyone to resolve it, I'm \
wanting it to not break things.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I'm happy with your changes. If what we have doesn't work now, it can \
proceed to not work, and we can add the additional new thing that fixes it. That's all great.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">What \
concerns me is the idea that it would stop the rest of plasma-workspace stable compiling for a whole \
month. That would have most packagers screaming at us.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">We just need to keep the old #define till \
frameworks 5.4</p> <blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">The real issue for breakeage is the use of \
plasmaquick </p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">That's \
a completely different topic and we should try not to get distracted by it.</p></pre> </blockquote>
<p>On August 29th, 2014, 3:05 p.m. UTC, <b>Marco Martin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">"We just need to keep the old #define till frameworks 5.4"<br \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> do you \
think it may be removed after 5.4 or better leaving it for the time being?<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> dataengine already has \
both, so i would put as a policy<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;" /> c) KPlugintTrader with a KServiceTypeTrade fallback<br style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
K_EXPORT_PLASMA_DATAENGINE K_EXPORT_PLASMA_PACKAGE etc, may be wrapped in an #idef \
no_deprecated</p></pre> </blockquote>
<p>On August 29th, 2014, 3:12 p.m. UTC, <b>David Edmundson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: \
-o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Once we have Plasma 5.1.0 out, I think it will be OK to sneakily remove \
it.<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" /> \
Your call.</p></pre> </blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; \
white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">if we do it, it may be worth to do in one go for \
dataengines, applets appletscripts as well</p></pre> <br />
<p>- Marco</p>
<br />
<p>On August 29th, 2014, 2:20 p.m. UTC, Aaron J. Seigo wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; \
border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for KDE Frameworks and Plasma.</div>
<div>By Aaron J. Seigo.</div>
<p style="color: grey;"><i>Updated Aug. 29, 2014, 2:20 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-framework
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid \
#b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">This patch set does the following:</p> <ul \
style="padding: 0;text-rendering: inherit;margin: 0 0 0 1em;line-height: inherit;white-space: normal;"> \
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">tidy \
up the data engine plugin loading code</li> <li style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;">make PackageStructure plugins use the json method as with \
DataEngines</li> <li style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">remove ShellPackage; it moves to live with plasmashell (review \
#119989)</li> </ul>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Ran a full Plasma Desktop \
session.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/plasma/packagestructure.h <span style="color: \
grey">(fb32c22a6e7df1528b3d7a5b30b94c60a85a93e3)</span></li>
<li>src/plasma/pluginloader.cpp <span style="color: \
grey">(d2ba5ca2d3a96fe6f1ce26be41df3b0954b924df)</span></li>
<li>src/plasma/private/packages.cpp <span style="color: \
grey">(5eb6f0021392257634dfd958c940b2945989e48b)</span></li>
<li>src/plasma/private/packages_p.h <span style="color: \
grey">(0833a4ed1b5704efffccade5e52589878e8b4957)</span></li>
<li>src/plasmaquick/CMakeLists.txt <span style="color: \
grey">(1ed7c67efcba0e6dbef1ff929b176090786503de)</span></li>
<li>src/plasmaquick/private/packages.h <span style="color: \
grey">(7498832d0537611903c13e544db6486bab163dd3)</span></li>
<li>src/plasmaquick/private/packages.cpp <span style="color: \
grey">(52758482230d271712e4bb3b6d33f8fdeaa848a8)</span></li>
<li>src/plasmaquick/shellpluginloader.h <span style="color: \
grey">(6c56e5f7b269c3af7587a58cbe104468a2c679c4)</span></li>
<li>src/plasmaquick/shellpluginloader.cpp <span style="color: \
grey">(2824760e6f64a694bd14b46d2f80151304e3e4d3)</span></li>
<li>src/plasma/dataengine.h <span style="color: \
grey">(d87a6f8361c892a249374a5c9da7e84836195156)</span></li>
<li>src/plasma/package.cpp <span style="color: \
grey">(6ad332167bb83c2f794f9f5d059e9f369ad33841)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/119988/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============1345080764530757542==--
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic