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

[Volker Hilsheimer]

> On 21 Jun 2021, at 10:38, Edward Welbourne  wrote:
> 
> On 18/06/2021 13:28, Edward Welbourne wrote:
>>> The very fact that we're generating PNGs at different resolutions from
>>> SVGs, when decent support for SVG would make that mostly redundant, says
>>> we should be fixing our SVG support (and making it efficient enough to
>>> make it practical to use it).
>>> 
>>>  Eddy, who illustrates geometry essays with hand-written inline SVGs.
> 
> Giuseppe D'Angelo (18 June 2021 15:22) replied:
>> Just to be The Grumpy One, this is:
>> 
>> 1) an immense task given QtSVG is fundamentally unmaintained;
> 
> Indeed - step one in fixing our SVG support would be finding someone
> willing (nay, enthusiastic) and able to take over maintaining QtSVG.
> 
>> 2) possibly an artistic anti-goal, given that artists want
>> 
>> * use of full SVG profile and not just tiny/basic profile (=
>>  implementation nightmare)
>> 
>> * full control over SVG rendering, something hard to guarantee;
>> 
>> * (related) not to rebuild+run the application after changing a SVG see
>> if there's something wrong in Qt's rasterized results;
>> 
>> * control over *lower* resolutions where one typically retouches the
>>  pre-rasterized results;
>> 
>> 3) a performance hit unless a SVG icon cache is put in place. Do we
>>   already a working, cross-platform one?
> 
> All of which comes under the heading of what I'd call "decent support
> for SVG".  As an author who routinely uses SVGs for illustrations, I've
> had occasion to try QtSVG out on diagrams I've written - and found the
> results embarrassingly underwhelming.  SVGTiny isn't really much use.
> Fortunately for me, web browsers generally do better.
> 
>   Eddy.

Thanks for the feedback, since step one is “put the assets under version 
control”, that’s what I did now with the SVGs I ran into in the course of 
addressing QTBUG-38776.

https://codereview.qt-project.org/c/qt/qtbase/+/355821

As per your comments, I put them into qtbase/src/widgets/styles/images, which 
is next to the PNGs that are based on them. There are also some XPMs in 
src/widgets/styles/qcommonstylepixmaps_p.h created from those SVGs, but even 
for those, styles/images is a rather obvious location (nevertheless, comment 
added to that header).

Cheers,
Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Edward Welbourne]

On 18/06/2021 13:28, Edward Welbourne wrote:
>> The very fact that we're generating PNGs at different resolutions from
>> SVGs, when decent support for SVG would make that mostly redundant, says
>> we should be fixing our SVG support (and making it efficient enough to
>> make it practical to use it).
>>
>>   Eddy, who illustrates geometry essays with hand-written inline SVGs.

Giuseppe D'Angelo (18 June 2021 15:22) replied:
> Just to be The Grumpy One, this is:
>
> 1) an immense task given QtSVG is fundamentally unmaintained;

Indeed - step one in fixing our SVG support would be finding someone
willing (nay, enthusiastic) and able to take over maintaining QtSVG.

> 2) possibly an artistic anti-goal, given that artists want
>
> * use of full SVG profile and not just tiny/basic profile (=
>   implementation nightmare)
>
> * full control over SVG rendering, something hard to guarantee;
>
> * (related) not to rebuild+run the application after changing a SVG see
> if there's something wrong in Qt's rasterized results;
>
> * control over *lower* resolutions where one typically retouches the
>   pre-rasterized results;
>
> 3) a performance hit unless a SVG icon cache is put in place. Do we
>already a working, cross-platform one?

All of which comes under the heading of what I'd call "decent support
for SVG".  As an author who routinely uses SVGs for illustrations, I've
had occasion to try QtSVG out on diagrams I've written - and found the
results embarrassingly underwhelming.  SVGTiny isn't really much use.
Fortunately for me, web browsers generally do better.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alessandro Portale]

We could store the icon graphics as serialized QPictures of "recorded" 
QSvgRenderer::render()s.
Of course only if we believe that QtSvg is able to render icons (which is what 
I believe, given that the "Iso Icons" do the same: 
https://doc.qt.io/qtcreator/qtquick-iso-icon-browser.html )

Alessandro

Von: Development  im Auftrag von Volker 
Hilsheimer 
Gesendet: Freitag, 18. Juni 2021 15:28
An: Nicholas Bennett 
Cc: development@qt-project.org 
Betreff: Re: [Development] Version-controlling the SVGs of built-in icons

> On 18 Jun 2021, at 14:06, Nicholas Bennett  wrote:
>
> I also would like to see the SVG support fixed, that appears to be address 
> the root cause.
>
> -Original Message-
> From: Development  On Behalf Of Edward 
> Welbourne
> Sent: Friday, 18 June 2021 2:28 PM
> To: Volker Hilsheimer 
> Cc: development@qt-project.org
> Subject: Re: [Development] Version-controlling the SVGs of built-in icons
>
> Volker Hilsheimer (18 June 2021 11:19) wrote:
>> 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.
>
> The very fact that we're generating PNGs at different resolutions from SVGs, 
> when decent support for SVG would make that mostly redundant, says we should 
> be fixing our SVG support (and making it efficient enough to make it 
> practical to use it).
>
>Eddy, who illustrates geometry essays with hand-written inline SVGs.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


Qt's SVG support lives in QtSvg, which is a separate module, and not even the 
same repository as qtbase.

Some of the topics at Qt Contributors Summit next week are about our repository 
structure, so that’s perhaps a good time to talk about whether QtSvg should be 
moved into qtbase, and perhaps merged with QtGui and QtWidgets, respectively.

What the performance implications are for rendering SVGs on demand (even when 
cached into a pixmap) needs to be evaluated as well.

Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Volker Hilsheimer]

> On 18 Jun 2021, at 14:06, Nicholas Bennett  wrote:
> 
> I also would like to see the SVG support fixed, that appears to be address 
> the root cause.
> 
> -Original Message-
> From: Development  On Behalf Of Edward 
> Welbourne
> Sent: Friday, 18 June 2021 2:28 PM
> To: Volker Hilsheimer 
> Cc: development@qt-project.org
> Subject: Re: [Development] Version-controlling the SVGs of built-in icons
> 
> Volker Hilsheimer (18 June 2021 11:19) wrote:
>> 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.
> 
> The very fact that we're generating PNGs at different resolutions from SVGs, 
> when decent support for SVG would make that mostly redundant, says we should 
> be fixing our SVG support (and making it efficient enough to make it 
> practical to use it).
> 
>   Eddy, who illustrates geometry essays with hand-written inline SVGs.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


Qt's SVG support lives in QtSvg, which is a separate module, and not even the 
same repository as qtbase.

Some of the topics at Qt Contributors Summit next week are about our repository 
structure, so that’s perhaps a good time to talk about whether QtSvg should be 
moved into qtbase, and perhaps merged with QtGui and QtWidgets, respectively.

What the performance implications are for rendering SVGs on demand (even when 
cached into a pixmap) needs to be evaluated as well.

Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Giuseppe D'Angelo via Development]

Hi,

On 18/06/2021 13:28, Edward Welbourne wrote:

The very fact that we're generating PNGs at different resolutions from
SVGs, when decent support for SVG would make that mostly redundant, says
we should be fixing our SVG support (and making it efficient enough to
make it practical to use it).

Eddy, who illustrates geometry essays with hand-written inline SVGs.


Just to be The Grumpy One, this is:

1) an immense task given QtSVG is fundamentally unmaintained;

2) possibly an artistic anti-goal, given that artists want

* use of full SVG profile and not just tiny/basic profile (= 
implementation nightmare)


* full control over SVG rendering, something hard to guarantee;

* (related) not to rebuild+run the application after changing a SVG see 
if there's something wrong in Qt's rasterized results;


* control over *lower* resolutions where one typically retouches the 
pre-rasterized results;



3) a performance hit unless a SVG icon cache is put in place. Do we 
already a working, cross-platform one?



My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Nicholas Bennett]

I also would like to see the SVG support fixed, that appears to be address the 
root cause.

-Original Message-
From: Development  On Behalf Of Edward 
Welbourne
Sent: Friday, 18 June 2021 2:28 PM
To: Volker Hilsheimer 
Cc: development@qt-project.org
Subject: Re: [Development] Version-controlling the SVGs of built-in icons

Volker Hilsheimer (18 June 2021 11:19) wrote:
> 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.

The very fact that we're generating PNGs at different resolutions from SVGs, 
when decent support for SVG would make that mostly redundant, says we should be 
fixing our SVG support (and making it efficient enough to make it practical to 
use it).

Eddy, who illustrates geometry essays with hand-written inline SVGs.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Edward Welbourne
> Sent: Friday, 18 June 2021 1:28 PM
> To: Volker Hilsheimer 
> Cc: development@qt-project.org
> Subject: Re: [Development] Version-controlling the SVGs of built-in icons
> 
> Volker Hilsheimer (18 June 2021 11:19) wrote:
> > 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.
> 
> The very fact that we're generating PNGs at different resolutions from SVGs,
> when decent support for SVG would make that mostly redundant, says we
> should be fixing our SVG support (and making it efficient enough to make it
> practical to use it).
> 
>   Eddy, who illustrates geometry essays with hand-written inline SVGs.

I agree with this. If the SVG is not too complex it should be efficient enough 
to just use them instead since they should only be rendered once at startup.

I think I remember Gunnar saying that Jolla did this for their icons.

> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Edward Welbourne]

Volker Hilsheimer (18 June 2021 11:19) wrote:
> 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.

The very fact that we're generating PNGs at different resolutions from
SVGs, when decent support for SVG would make that mostly redundant, says
we should be fixing our SVG support (and making it efficient enough to
make it practical to use it).

Eddy, who illustrates geometry essays with hand-written inline SVGs.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Shawn Rutledge]

> On 2021 Jun 18, at 11:19, Volker Hilsheimer  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ø  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.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Brook Cronin]

To add to this, for the Design Studio property editor and in some cases beyond 
we have moved to using an icon font for all our icons. We have a collection of 
python scripts that generate a ttf font from a folder of svg images and then 
create a csv of the unicode values and corresponding mapping qml file to use 
icons from the font via their qml id.

There are also c++ helper functions available to render the qml icon font into 
qpixmap for cases where qml cannot be used directly.

If anyone is interested in finding out more about our icon pipeline just give 
me a shout, my plan is to create a web service for generating these fonts 
yourself in an upcoming hackathon.

Best,

Brook.



On 18. Jun 2021, at 12:00, Alessandro Portale 
mailto:alessandro.port...@qt.io>> wrote:

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 
mailto:development-boun...@qt-project.org>> 
im Auftrag von Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Gesendet: Freitag, 18. Juni 2021 11:19
An: development@qt-project.org 
mailto:development@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@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mitch Curtis]

For completeness since Alessandro mentioned exporting: for qtquickcontrols2, 
I've been using the same Inkscape extension that we document for exporting 
9-patch images, since it also works with regular images:

https://doc.qt.io/qt-5/qtquickcontrols2-imagine.html#exporting-9-patch-images

From: Development  On Behalf Of Alessandro 
Portale
Sent: Friday, 18 June 2021 12:00 PM
To: Volker Hilsheimer ; development@qt-project.org
Subject: Re: [Development] Version-controlling the SVGs of built-in icons

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 
mailto:development-boun...@qt-project.org>> 
im Auftrag von Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Gesendet: Freitag, 18. Juni 2021 11:19
An: development@qt-project.org 
mailto:development@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@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [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  im Auftrag von Volker 
Hilsheimer 
Gesendet: Freitag, 18. Juni 2021 11:19
An: development@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@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Volker Hilsheimer
> Sent: Friday, 18 June 2021 11:20 AM
> To: development@qt-project.org
> Subject: [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?

Hi Volker.

I've been adding source SVGs for PNG icons in the module itself in the case of 
qtquickcontrols2:

mitch@mitch-ubuntu-20:~/dev/qt-dev/qtquickcontrols2$ find . -name "*svg"
./tests/auto/qquickiconimage/icons/testtheme/appointment-new.svg
./examples/quickcontrols2/wearable/qml/Settings/images/theme.svg
./examples/quickcontrols2/wearable/qml/Settings/images/demo-mode.svg
./examples/quickcontrols2/imagine/automotive/icons/automotive/icons.svg
./examples/quickcontrols2/imagine/musicplayer/icons/musicplayer/icons.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/up-icon-thick-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/crumb-separator-icon-round.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/file-icon-round.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/up-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/folder-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/file-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/up-icon-round.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/imagine/filedialogdelegate-background.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/crumb-separator-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/folder-icon-round.svg
./src/quickcontrols2/material/images/drop-indicator.svg
./src/quickcontrols2/material/images/arrow-indicator.svg
./src/quickcontrols2/doc/images/qtquickcontrols2-control.svg
./src/quickcontrols2/doc/images/qtquickcontrols2-popup.svg
./src/quickcontrols2/fusion/images/arrow.svg
./src/quickcontrols2/fusion/images/progressmask.svg
./src/quickcontrols2/fusion/images/checkmark.svg

I would vote for keeping the icons in the modules where they're used. Ideally 
that would be next to the generated images, as that makes it easy to find them 
and is an easy convention to follow.

I'm not sure how many designers use Git to be honest. Most of my interactions 
with designers have involved exchanging files through email/chat/file hosting. 
If they are using Git though, I wouldn't think it would matter too much where 
the files are, because that still needs to be communicated up front before the 
work begins.

Cheers.

> 
> Volker
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Tor Arne Vestbø]

Hey hey, 

Thanks for bringing this up, I’ve been in that situation myself, for example 
looking for diagrams in the documentation.

I generally think that assets that make up a product should live together. That 
is, the source code, image assets, docs, examples, tests, etc, for a 
module/library.

I understand the argument of easier access for digital artists, but I think 
that can be solved by partial/sparse git clones and the like, at least to a 
degree that votes in favour of keeping stuff together.

Cheers,
tor arne

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Volker Hilsheimer]

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@qt-project.org
https://lists.qt-project.org/listinfo/development