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.
+10 for all the proposals about icons. This problem is recurring, popular, old and unfortunately without any beginning of resolution! so my question: do you think you will address this UI issu soon? regards
*** Bug 163420 has been marked as a duplicate of this bug. ***
*** Bug 164661 has been marked as a duplicate of this bug. ***
*** Bug 165782 has been marked as a duplicate of this bug. ***
*** Bug 162270 has been marked as a duplicate of this bug. ***
*** Bug 169128 has been marked as a duplicate of this bug. ***
I would like to work on this bug but I would very much need some code pointers. Can anyone help me with that?
I had a look at the code and found something that confused me a little so I wanted to ask if somebody could give me an explenation. In the file CommandImageResolver.cxx I found the following code: std::map<std::tuple<ImageType, ImageWritingDirection>, OUString> const ImageType_Prefixes{ { { ImageType::Size16, ImageWritingDirection::DontCare }, u"cmd/sc_"_ustr }, { { ImageType::Size26, ImageWritingDirection::DontCare }, u"cmd/lc_"_ustr }, { { ImageType::Size32, ImageWritingDirection::DontCare }, u"cmd/32/"_ustr }, { { ImageType::Size16, ImageWritingDirection::RightLeftTopBottom }, u"cmd/rltb/sc_"_ustr }, { { ImageType::Size26, ImageWritingDirection::RightLeftTopBottom }, u"cmd/rltb/lc_"_ustr }, { { ImageType::Size32, ImageWritingDirection::RightLeftTopBottom }, u"cmd/rltb/32/"_ustr }, }; Now as I understand it there are the sizes 16x16, 26x26 and 32x32. But when having a look at the readme here https://git.libreoffice.org/core/+/refs/heads/master/icon-themes it says that the sizes should be 16x16 and 24x24. Can somebody explain to me why the code uses the size 26x26?
(In reply to tanuki.ej9mr from comment #20) > Now as I understand it there are the sizes 16x16, 26x26 and 32x32. But when > having a look at the readme here > https://git.libreoffice.org/core/+/refs/heads/master/icon-themes it says > that the sizes should be 16x16 and 24x24. Can somebody explain to me why the > code uses the size 26x26? You could've checked the ImageSize enum definition as there is a comment: // The exact sizes of the icons in each size grouping are not necessarily // the exact size indicated by the name, but the upper limit of their size. // e.g. many Size26 icons are often 24x24px and only some 26x26px
I think all internal icon themes today are 24x24 and in practice all icon themes should be 24x24, but the name "Size26" persisted mainly because nobody cared or be bothered with to change it to "Size24" now that we mostly standardized on 24x24 size.
(In reply to Tomaz Vajngerl from comment #22) > I think all internal icon themes today are 24x24 and in practice What about SVG themes? > all icon themes should be 24x24 Are you sure? I mean, what's the inherent problem with icon themes of other icon dimensions? Especially when we're talking about multiple variants?
(In reply to Eyal Rozenberg from comment #23) > (In reply to Tomaz Vajngerl from comment #22) > > I think all internal icon themes today are 24x24 and in practice > > What about SVG themes? The icons there should be defined as 24x24 in size or I don't understand what you mean. > Are you sure? I mean, what's the inherent problem with icon themes of other > icon dimensions? Especially when we're talking about multiple variants? Not sure what you mean... I'm talking specifically about command icons (which as you see the context of my answer is) starting with lc_ in name that are 24x24 or some legacy icons that were 26x26 in size which we don't use anymore AFAIK.
I suspect @quikee was just addressing the apparent disparity between our 24px and 26px of the core command lc_ icons. The goal for this issue remains the repackaging of our icon themes into a more cohesive format, one that bundles the theme designer's icons in PNG at useable pixel size along with the "scalable" SVG for dynamic rendering in response to UI scaling. Could be the suggested FreeDesktop spec [1] but could be something organic to our needs. Ideal would be to support response to os/DE color sense change and for example allow user control to use a single Icon theme e.g. simply Breeze or Colibre, and then automatically switch between the light and the dark flavors of the icons at the scaling factor they operate their os/DE. What ever is needed drawn from the icon theme package. And likewise but more complex allow user with Appearance themes enabled (or the appearance theme designer) to specify the icon theme they'd like for os/DE in Light color sense, and a different icon theme when in Dark color sense. =-ref-= [1] https://specifications.freedesktop.org/icon-theme/latest/
I assigned the task to myself and will try my best to implement the freedesktop icon theme specification (https://specifications.freedesktop.org/icon-theme/latest/).
While having a look at the icons, I found some icons which seemingly appear twice. Can someone tell me if there is a reason for that or if the duplicate icons could be removed? List of duplicate icons I found so far: - "...\lo\libo-core\icon-themes\breeze\res\helpimg\warning.png" - "...\lo\libo-core\icon-themes\breeze\res\helpimg\tip.png" - "...\lo\libo-core\icon-themes\breeze\res\helpimg\note.png" - "...\lo\libo-core\icon-themes\breeze\vcl\res\warningbox.png" - "...\lo\libo-core\icon-themes\breeze\vcl\res\successbox.png" - "...\lo\libo-core\icon-themes\breeze\vcl\res\infobox.png"
I tried to order the icons according to the Icon Theme Specification (see https://specifications.freedesktop.org/icon-theme/latest/). For my first attempt I decided not to merge the different colour and png/svg variants into one folder. The reason behind that is simply because it requires less work. This ultimately resulted in the following folder structure for the theme breeze. Now I'm wondering myself if this is really the desired result breeze ├───10x10 │ └───svx ├───10x22 │ └───svx ├───11x11 │ ├───dbaccess │ ├───res │ ├───sd │ ├───sfx2 │ ├───svtools │ └───svx ├───11x16 │ ├───cmd │ └───sc ├───11x33 │ └───svx ├───11x9 │ └───svx ├───120x140 │ └───avmedia ├───128x128 │ ├───res │ └───sfx2 ├───12x12 │ ├───desktop │ ├───extensions │ ├───sc │ └───sw ├───13x13 │ └───svx ├───13x14 │ └───sfx2 ├───14x14 │ └───svtools ├───150x150 │ └───res ├───15x15 │ ├───svx │ └───vcl ├───15x17 │ └───sw ├───16x13 │ └───sw ├───16x14 │ └───sfx2 ├───16x16 │ ├───chart2 │ ├───cmd │ │ ├───ar │ │ ├───de │ │ ├───es │ │ ├───fr │ │ ├───hu │ │ ├───id │ │ ├───it │ │ ├───km │ │ ├───ko │ │ ├───nl │ │ ├───pl │ │ ├───rltb │ │ ├───ru │ │ ├───sl │ │ └───tr │ ├───dbaccess │ ├───desktop │ ├───extensions │ ├───formula │ ├───fpicker │ ├───reportdesign │ ├───res │ ├───sc │ ├───sd │ ├───sfx2 │ ├───svx │ ├───sw │ └───xmlsecurity ├───16x17 │ └───svx ├───16x18 │ └───res ├───16x24 │ └───svx ├───16x26 │ └───sw ├───16x27 │ └───sw ├───16x32 │ └───svx ├───16x4 │ └───sfx2 ├───18x140 │ └───svx ├───18x18 │ └───sc ├───19x19 │ └───sd ├───22x22 │ ├───cmd │ └───svx ├───24x24 │ ├───chart2 │ ├───cmd │ │ ├───ar │ │ ├───de │ │ ├───es │ │ ├───fr │ │ ├───hu │ │ ├───id │ │ ├───it │ │ ├───km │ │ ├───ko │ │ ├───nl │ │ ├───pl │ │ ├───rltb │ │ ├───ru │ │ ├───sl │ │ └───tr │ ├───extensions │ ├───res │ ├───sc │ ├───sd │ ├───sfx2 │ ├───starmath │ ├───svx │ └───sw ├───256x176 │ └───res ├───25x190 │ └───vcl ├───26x26 │ └───sw ├───30x30 │ └───chart2 ├───31x31 │ └───sw ├───32x32 │ ├───cmd │ │ ├───ar │ │ ├───de │ │ ├───es │ │ ├───fr │ │ ├───hu │ │ ├───it │ │ ├───km │ │ ├───ko │ │ ├───nl │ │ ├───pl │ │ ├───rltb │ │ ├───ru │ │ ├───sl │ │ └───tr │ ├───desktop │ ├───framework │ ├───res │ ├───sd │ ├───sw │ ├───vcl │ └───wizards ├───40x56 │ └───xmlsecurity ├───43x108 │ └───vcl ├───43x43 │ └───sc ├───48x48 │ └───res ├───52x60 │ └───chart2 ├───54x68 │ └───sd ├───57x71 │ └───sd ├───58x73 │ └───sd ├───63x153 │ └───svx ├───65x90 │ └───sc ├───7x7 │ └───svx ├───7x9 │ └───svx ├───80x80 │ └───svx ├───8x8 │ └───vcl ├───92x117 │ └───svx ├───96x96 │ ├───res │ └───starmath ├───9x11 │ └───svx ├───9x7 │ └───svx ├───9x9 │ └───svx └───color_scheme
(In reply to tanuki.ej9mr from comment #27) > icons... appear twice. ... could be removed? Search for the file name and you find the internal variable. Check the code how this variable is used and decide if some icon can be replaced by another (links.txt comes in handy for this purpose). \helpimg and \vcl are definitely different. Not commenting on the freedesktop scheme questions.
(In reply to tanuki.ej9mr from comment #28) > I tried to order the icons according to the Icon Theme Specification (see > https://specifications.freedesktop.org/icon-theme/latest/). For my first > attempt I decided not to merge the different colour and png/svg variants > into one folder. The reason behind that is simply because it requires less > work. This ultimately resulted in the following folder structure for the > theme breeze. > > Now I'm wondering myself if this is really the desired result What we need is just additional metadata about the icon theme so we know what it contains, not restructuring the whole icon theme to what the icon theme specification says. We don't really care if we are specs compliant or not, just good to not reinvent the wheel regarding how the metadata is written. Any change to the folder structure or filename of the icon will necessarily require a change in the code also and this will be a lot of work for very little benefit.