[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