Current icon themes are packed in infinitely naïve way: a zipped directory (which name consisting of a single "word" (!) makes its UI name (tdf#141000 is an example of a palliative attempt to make it somehow work)) filled with tons of sub-directories, image files, and a "links.txt" mapping those images to internal resource names - but no metadata like true name, version, or icon variants. This makes many things impossible. You can't have normal names (e.g., some characters are prohibited in file names on many FS); you can't have versioning; you can't make themes support dynamically changing environments (switching night mode, dark mode, different resolutions, etc.) which is common today - the resolution may change when a window moves from one monitor to another, and day/night or light/dark mode may change depending on time of the day. Icon themes get multiple items in the View->Icon Style list: Breeze; Breeze (SVG + dark); Breeze (SVG); Breeze (dark) ... The normal icon theme should: 1. Include normal metadata that would allow to have normal naming independent on the filename, versioning, integrity hash, copyright, etc.; 2. Allow to contain several variants (e.g. light and dark), allowing application to choose relevant variant of the user-chosen theme automatically depending on environment; 3. In each variant, allow to have multiple resolutions (ideally, a vector - SVG - and optionally several pre-rendered bitmap variants for typical and/or hard-to-render-automatically resolutions); 4. Each resource should also allow to have several sizes (to minimize proliferation of resource variants, when we need "small" and "large" resources e.g. for toolbars depending on user's toolbar button size preference). There needs to be a re-design of the icon theme packing concept/design to include these (and maybe others?) considerations.
+1 for update the icon packaging. about the licence and other information stuff, we can use the "packaging" of our extensions. There most stuff should be already available like maintainer, license, ... description. All icon themes within LibO core area available as svg files AND were done first as svg file (inkscape). So the png files (which was used by LibO) are only renderd from the svg files. Light / Dark ------------ The colibre icon theme was done for light and dark. Dark icons are NOT ONLY use other colors. Most icons are black -> white but there are icons which are different like you see a sun on insertgraphic and a moon in dark mode. Be aware of this. png --- since 6.4 I wait for native svg icon theme support that look good. We are all for svg icon theme support, but the quality is now bad. package ------- from my point of view it's enough that the complete package has one license so no need for file specific informations. sc_ lc_ ------- it's ok(isch) that libreoffice icons didn't use freedesktop icon names, but it would be nice if it does. What is a pain are the prefix sc_ for 16px and lc_ for 24px icon sizes. the 32px icons already have a separate folder. It would be nice if the sc_ and lc_ files will also get there separtae folder. about folders. I didn't know why there are cmd, sw, sd, ... folders. from a designer point of view ALL icons could be in one folder depend on the size. Like we know from gnome/kde, ... icon themes.
I would help with all the changes, but from my point of view a good time for this changes would be the switch to svg icons.
+1 for the metadata. But mixing different themes into one file sounds not like a good idea. This means, for example, you pick first Yaru (available from the extensions site) and then the flavor (1 out of ~10). Kendy had the idea to alternate SVG icons so colors would be user-configurable (see also bug 124966). Seems to be more flexible. Missing in your list of issues is bug 124956 with all the icons that depend on locale settings, the reading direction, etc.
Another issue about mixing light/dark theme is that LibO has a lot (to much) icons so it's a lot of work to initial make an icon theme for LibO. Have there light and dark would be result in additional work, so evern less community members would support LibO with there icons. So one goal has to be also to minimize the work as much as possible (different color -> color scheme for svg icons replace #fff with #000 simple and usefull. You only have to add an color scheme file.
In addition we (I) could offer a links.txt file where the freedesktop filenames will be translated to the LibO icon names. This would help icon designers a lot to support there work within LibO. maybe it's a different task, than let's make a separate bug report, if a developer will offer support for a second freedesktop.txt file which will look like links.txt and link the freedesktop.org filename with LibO ones.
*** Bug 152498 has been marked as a duplicate of this bug. ***
Also need some thought on how we would define and bundle combined SVG and PNG original icon artwork, at multiple resolutions. As for bug 150973
wrt comment #7 and comment #1 point 3 there is the freedesktop spec https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html which is what gnome does, so on my filesystem: $ ls /usr/share/icons/Adwaita 128x128 16x16 22x22 24x24 256x256 32x32 48x48 512x512 8x8 icon-theme.cache index.theme scalable where the scalable are svg, e.g. /usr/share/icons/Adwaita/scalable/ui/checkbox-checked-symbolic.svg and the explicit sizes are png, e.g. /usr/share/icons/Adwaita/32x32/ui/checkbox-checked-symbolic.symbolic.png
Current discrete icon theme packaging ( [1] light, dark, and SVG variants for each theme) forces user action in the UI to set icon theme as an option. IIUC our automatic response to DE color theme currently seems limited to use of the PNG packaged themes. And because when increasing UI scaling, or moving to HiDPI screen resolutions, we don't automate the shift to SVG variants and UI suffers pixilation. Adjusting icon theme packaging to deploy and parse just one library per icon theme would need refactoring of the UI and the automated response (to color theme, screen resolution and scaling) but it would provide better UX. Complexity would increase, requiring more work and possibly adopting a standard [2] for consistent icon theme design and maintenance, but our 'Automatic' response in UI could be made more functional for users. Avoiding issues like bug 153465 on macOS. Also, worth a revisit to Andreas's work on bug 124966 [3] for providing hooks to toggle colors within the SVG to respond to standard/dark color theme use. The framework is there in Breeze, Colibre, and Sifr but didn't seem to be pursued as icon theme development went on. So, +1 to move forward on better icon theme packaging. =-refs-= [1] https://opengrok.libreoffice.org/xref/core/icon-themes/ [2] Possibly https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html but not clear to me that we could overload .hicolor with our light/dark theme needs. But maybe [3] provides. [3] https://gerrit.libreoffice.org/c/core/+/71330/
Haven't seen any -1, so let me put the fly in the ointment. Some requirements are mixed here: 1) Lower the packaging burden for icon designers (file structure) 2) Don't use file names as variable in the UI 3) Improve code readability (links.txt) 4) Make variants easier accessible/shiftable (day/night, low/hires) 5) Clean up the UI (confusing list of icon themes in options) Doubt 1) is achieved if the data is not stored in folders but nodes, 2) could be solved easily with some "name.txt" file in the package, 3) somehow the complexity will remain, 4) could be realized per code as today, 5) +1. Following the freedesktop spec (comment 8) adds even more structure. And the alternative is an own icon format similar to Apples icns pack. Not bad per se but requires special tools. Still +1 from my side (no need for more UX input, I guess)
I agree with all these points. In addition, I would like to specifically ask about a way to inherit themes. Ubuntu ships with several colour variants and I'd like to have a root theme and some colour variants that inherit the latter. Because the current situation is really sub-optimal: we have of a lot of duplicated icons, which makes the full pack very heavy on disk space (~110mo).
One more additional point: excellent support for RTL and CJK writing. I think these ones and inheritance can be achieved by following FreeDesktop scheme.