KSvg in kdereview

[Marco Martin]

On Fri, May 12, 2023 at 3:41 PM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Did some small fixes (library e.g. was installed with literal ".SOVERSION" as
> suffix...), but the more I did and more I saw... IMHO this should not have yet
> been passed to kdereview, being in alpha state for my taste.

ouch, sorry :/ and thanks
one thing that will make the landing even longer is that at the plasma
sprint we decided it was the case
 for making it depend from a new (also not yet landed) framework (the
new home for KColorScheme) so
it will still take more time.

> E.g. "TODO KF6" ideally would not be handled during the review phase, but
> before.

there was still one todo kf6 which after some tought and discussion
was then removed
as doing that it would cause a regression in themes we don't want.

> And the README and other docs not (yet) mentioning what the scope & purpose of
> the library, but being dead copies from Plasma Framwworks also makes things
> harder to assess.

ok, i'll write a more comprehensive introduction there

> Builds on CI all failing ever since and before also looks a bit unattractive.
> Currently still with FreeBSD.

fixed it now

> For the name, "KSvg" sounds very unspecifc to me, ideally the name would
> reflect the purpose & scope of the library some more (but then that is not
> defined somewhere also, so... ;) ). Something with SVG, but what exactly?
> Perhaps "KSvgTheme" (proposed by Sune on irc) or similar might make it more
> clear?

I'm not sure, compared to the plasma version the "theming" part has
been scaled down a bit
(so that the "theme" class becaume "imageset" as most of the
kcolorscheme wrapping api is gone)
I'm not opposed to changing the name again, but not sure what other
names could actually be more clear.
so, basically the things that does over qsvg (the why for using qtsvg
not directly) are:

* disk caching of the rendered pixmaps to have things faster
* stylesheet based recoloring
* the fact that svgs can come in bundles (the theming part, tough is
not the main thing, so i would not give the name of the whole library
after that)
* the 9 patch framesvg for doing rectangular things
* qml bindings

> Also using "KSvg" as namespace results in class names like KSvg::;Svg,
> KSvg::SvgItem, etc. which looks a bit strange to my eyes on consumer side due
> to the duplication. In my perfect world the naming would see some overhaul
> given this is a new library. Yes, some one-time porting pain, but sanity
> afterwards, for a certain type of sustainability ;)

one thing is that the library is really about svgs and nothing else,
and the Svg class is about rendering one single svg,
so I don't see many ways around about both contianing "svg" ? (I was
aware there was an old kde3 ksvg library,
 though talking about it in some tuesday meeting didn't seem to be an issue)
Open to ideas :)

-- 
Marco Martin