Re: [kde-artists] oxygen style and kwin client, svn external

Aaron J. Seigo wrote:
> a blocker for the git migration is the usage of svn externals. they are a
> broken concept that we need to get away from. there is one in kdebase between
> runtime/kstyles/oxygen/lib and workspace/kwin/clients/oxygen/lib.
>
> next is to get rid of the svn external altogether, which contains the Helper
> and TileSet classes. both have non-trivial amounts of code in them and it is
> indeed useful to share them. there are two options i can see here:
>
> * create a static lib in runtime that both kwin client and qstyle can link
> against. pros: the actual source code is shared, no runtime linkage overhead.
> cons: the code is duplicated in both plugins.

it is already duplicated today so that is no big issue. The issue was 
rather that the lib would have to be shipped by something, at which 
point kdebase-runtime isn't really an option(?¹), and you still have the 
cons of having to make it very, very clear that it is for internal use only.

(¹ Is kdebase-runtime allowed to be a build-time dependency of 
kdebase-workspace?)

And... I don't think you gain anything over the shared lib, since you 
have the same risk with not matching kdebase-workspace and -runtime 
(though only at build time). And I think you still end up needing a 
cmake module to find the lib.

Out of those options, I tend to agree with apaku that shared would be 
better.

What about git submodules, I thought that was supposed to solve this 
problem?

> * keep a copy of the files (4 of them; 2 headers, 2 imlementations) in both
> runtime and workspace and hand-synchronize them when needed. pros: it's the
> "least works right now" solution, cons: it's the most "require vigilance in
> the future" solution. TileSet doesn't seem to have changed very rapidly, but
> Helper has gone through it's fits and starts

Helper... basically must remain 100% in sync; any deviation is likely to 
cause the deco and style to not blend together as intended. (Actually a 
shared library would be better here, since you'd have the best shot of 
this being right if you have different versions of the style and deco.)

IMHO the best solution is to not have the style and deco in different 
modules :-). But that's problematic as well.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's not easy for [Microsoft] to accept [competing fairly]"
   -- Dave Heiner (a Microsoft VP, paraphrased)

______________________________________________________________________________
[email protected] |  https://mail.kde.org/mailman/listinfo/kde-artists