[Development] Version-controlling the SVGs of built-in icons

[Shawn Rutledge]

> On 2021 Jun 18, at 11:19, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
> 
> Hi,
> 
> 
> The majority of time spent on QTBUG-38776 is chasing down the various SVGs from which it’s then trivial to generate PNGs in different resolutions.
> 
> Which makes me think that we should have those SVGs version controlled somewhere. That “somewhere” can either be the respective module repositories, or a dedicated repo with all SVGs. I’m in favour of the latter option, mostly because it makes it easier for the digital artists who create and maintain those SVGs to do that without having to clone the world and navigate a rather complex repo and file system structure. But there are pros and cons to either approach.

I agree with the other comments: it makes sense to store them alongside the code.  Maybe the build system could even generate raster formats from them, if it ever ends up seeming worth the trouble.  PNGs don’t need to change very often, but then again there’s mipmapping for high-dpi, compressed texture formats, etc.  Generating icns format is some trouble on macOS, and I wonder if that could be automated.  Likewise ico format on Windows.  So I think treating svg as just another kind of source code makes sense.  There’s also the possibility of just using the SVGs directly: they take a little time to render, but they can be scaled appropriately for any screen.

> On 2021 Jun 18, at 11:37, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:
> 
> Hey hey, 
> 
> Thanks for bringing this up, I’ve been in that situation myself, for example looking for diagrams in the documentation.

Especially documentation diagrams should live in the code repo IMO, even in cases where we aren’t using them in qdoc-generated documentation.  User-facing documentation is not the only kind that we should have: it would be easier for new Qt developers to come up to speed if we had also more docs about internal architecture.  In qtdeclarative I’ve started using \internal doc comments more, because doxygen can find them and generate an “internal” documentation set (complete with UML diagrams for every class!)  So if those internal code docs also linked to diagrams of our own creation, it would find those too.