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

[Alessandro Portale]

Very interesting topic, indeed. Thanks.

In order to support High-DPI and themed looks in Qt Creator, we switched from a decade-old collection of PNGs with unknown origins inconsistent looks to having everything in an SVG document under source control:
  https://github.com/qt-creator/qt-creator/blob/master/src/tools/icons/qtcreatoricons.svg
That SVG is considered "proper source code" and updates happen in the same commit along with the resulting @1x/@2x PNGs, and the C++ code that integrates the icon.

There is a little python script that automates exporting and optimizing the PNGs. https://github.com/qt-creator/qt-creator/blob/master/src/tools/icons/export.py
Gimmick: The PNGs are generated in the position of the source tree where they will be added to the repository.

The stuff in Qt Creator is a bit self-baked regarding the namings, etc. I would not mind having a unified approach across the repositories.

Br,
Alessandro
________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Volker Hilsheimer <volker.hilsheimer at qt.io>
Gesendet: Freitag, 18. Juni 2021 11:19
An: development at qt-project.org <development at qt-project.org>
Betreff: [Development] Version-controlling the SVGs of built-in icons

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.

Since that might become the place for scalable versions of all icons, including those for Qt Creator and Qt Design Studio, having such a repo under the “qt" namespace seems odd. But I don’t see any obviously better option either.

Any opinions?


Volker


_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210618/1a53663e/attachment.html>