Hi! Currently, the Breeze icons are all scalable vector graphics placed in a rather unusual directory hierarchy. This results in the following problems: * In order to be efficient, we need to render a cache of SVG icons, which costs CPU cycles. * The icon-cache needs to be stored per-user, meaning that we duplicate larger amounts of data in each user account, which could actually be shared between them. That is especially bad on a remote filesystem. * Rendering SVGs on mobile devices with slower CPU can be very expensive, and even if it is just done once it results in a bad first start experience, especially when opening an application with lots of small icons in the menus. * The icon-cache can go out-of-date and needs to be rebuilt everytime the distributor (or developer) touches the icon-theme for any reason. * Due to the unusual directory layout, we can't use the Breeze theme as icon-source for AppStream metadata yet and fall back to Oxygen instead. To elaborate a bit on the last point: "Unusual" directory layout means that the Breeze theme does not follow the directory layout of the default hicolor icon theme. As defined in the spec[2], the actual layout is defined by the index.theme file, but traditionally a <size>/<category> layout is used, e.g. "64x64/apps" or "scalable/categories". The Breeze theme is the only desktop default theme I found in the Debian archive which has that layout (it's also used by e.g. the Faenza iconset, but that's an extra theme, not a desktop default. GNOME, MATE, Xfce4, ... all use the traditional layout, and so did the Oxygen icon theme). So, for the AppStream icon extractor, I would need to write new code specifically for the Breeze theme, which isn't ideal (currently, we use Oxygen icons for KDE apps). So considering to change the layout while building the bitmaps might be an idea. To be clear, dropping the SVG icons is not what this report is about, and I also don't want bitmaps to be stored in the Git repository. The idea is to have them rendered at build-time and stored into a directory structure like --- /usr/share/icons/breeze/ ├── 128x128 │ ├── actions │ ├── animations │ ├── apps │ ├── categories │ ├── devices │ ├── emblems │ ├── emotes │ ├── filesystems │ ├── intl │ ├── mimetypes │ ├── places │ ├── status │ └── stock │ ├── chart │ ├── code │ ├── data │ ├── form │ ├── image │ ├── io │ ├── media │ ├── navigation │ ├── net │ ├── object │ ├── table │ └── text ├── 24x24 │ ├── ... ├── 64x64 │ ├── ... ├── scalable │ ├── ... └── ... --- (or keep the current structure, but render the icons) Thanks for considering! In case this is accepted, I'd work on making cmake do the job. [2]: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout Reproducible: Always
I'm not a big fan of using png files cause 1. we work on svg files so if we change something we have to sync the png files as well 2. git doens't work well with png files 3. the symbolic links have to work also for the png files (be aware of it) I would prefer something like a script when the icons were released the png files will be generated automatically. I like standards and if we don't use the standard folder structure I can change it.
(In reply to andreas from comment #1) > I'm not a big fan of using png files cause > 1. we work on svg files so if we change something we have to sync the png > files as well > 2. git doens't work well with png files Yes, working with PNG as source material is not a good idea, that's why having an intermediate "make" step makes sense, which compiles the actual icon theme from the SVG source material. > 3. the symbolic links have to work also for the png files (be aware of it) That's an issue, but a solvable one. > I would prefer something like a script when the icons were released the png > files will be generated automatically. If you want to, I can come up with a script, or - since the breeze-icons repo already contains C++ code, with a small C++ helper application which does the conversion and symlinking in a user-friendly way. The advantage of using compiled code would be that it allows using QtSVG (which results in the same rendering as the current widgets get). > I like standards and if we don't use the standard folder structure I can > change it. It's not exactly a standard, but more a convention ;-) Building the folder structure at build-time would work too (and is probably necessary), so you could organize the files as you wish in the Git repo.
Hi I remove a lot of unused svg text infos and now the icons have stylesheeds and are smale in size. so if you want to change the icons do it on runtime or when you install the icons. in the repository there will be only svg files. I hope this will work for you, cause I will work on svg files and png files are not needed for my work if it is better for the user, than convert the icons while install the svg files.
> if it is better for the user, than convert the icons while install the svg files. That's what Matthias asks for with this bug report...
Yes, storing bitmaps in Git would be insane... Still, the SVG images are a problem due to the issues outlines above, and compiling them to a reasonable amount of bitmaps at build-time should be easily possible. Unfortunately I have quite a lot of stuff to do at time, so creating a patch isn't at the top of my priority list - but it's on there :-) The stuff I wrote about changing the icon layout can be ignored btw, that was a quirk in the AppStream generator which has been resolved meanwhile, and there is really nothing to be gained by changing it. Although, if/when bitmaps are shipped, some layout changes would be useful...