On Fri, May 12, 2023 at 3:41 PM Friedrich W. H. Kossebau <kosse...@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