Re: [Development] Version-controlling the SVGs of built-in icons
> 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] 2 days to go until Qt Contributors Summit 2021
> On 20 Jun 2021, at 11:05, Volker Hilsheimer wrote: > > Hi, > > The Qt Contributors Summit 2021 is only two days away! > > The program lives at > > https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program > > and will change a little as we get closer to the event, so bookmark and/or > watch that page. Note that the times are in CEST, and that we start at 9am on > both Tuesday and Wednesday. > > We have room for more sessions, so don’t hold back and fill the space with > anything you’d like to share with the community or discuss with other > contributors. > > We start and end the event with a couple of all-hands sessions, and otherwise > break out into four parallel tracks. All tracks will be hosted in Big Blue > Button rooms provided by KDE (links in the program page), and you can join > the discussion via IRC (#qt-cs channel on Libera.chat) or via Matrix: > > https://matrix.to/#/#qt-cs:kde.org > > If you have not registered yet, please do it now to get access to the event: > > https://akademy.kde.org/2021/register > > > See you soon! > > Volker I’ve now shared access to the four breakout rooms with those session owners that have an account in the system (and if you don’t, then you know what you do). I’ve also started the Main room, so if you wanna double-check your setup, point your browser at https://meet.kde.org/b/qtcs-main-room I’m not watching that window, so if you are having IT troubles that you think I can help you with (which is quite unlikely), ping me (nick: vohi) on https://matrix.to/#/#qt-cs:kde.org 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
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
