| Summary: | SVG icon types set to Fixed (prevents scaling & messes up Gtk apps) | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Ian Pilcher <arequipeno> |
| Component: | Icons | Assignee: | Uri Herrera <uri_herrera> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andreas_k, kainz.a, rdieter |
| Priority: | NOR | ||
| Version: | 5.4.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://bugzilla.redhat.com/attachment.cgi?id=1092537 | ||
| Latest Commit: | http://commits.kde.org/breeze-icons/d54ef43f4add1389ab5536ddc6cc3587aced6099 | Version Fixed In: | |
|
Description
Ian Pilcher
2015-11-11 17:44:58 UTC
No, actually (you can check yourself) that icon is an status icon. One that is used for dialogs in fact. You can see that the rest of the toolbar icons, with the exception of the two that are missing, are showing up correctly. Evidently, Breeze is not meant to be used with GTK software but we have added toolbar icons in the size that GTK software uses (24px). So: 1) Virt-manager is using an icon that is not meant to be used in a toolbar (dialog-information). 2) There are toolbar icons that are indeed missing. 3) We do provide 24px icons for GTK software. (In reply to Uri Herrera from comment #1) > 1) Virt-manager is using an icon that is not meant to be used in a toolbar > (dialog-information). > 2) There are toolbar icons that are indeed missing. > 3) We do provide 24px icons for GTK software. I'm really not in a position to comment on whether virt-manager is doing something "wrong" here (although wanting to use a themed "information" icon seems pretty reasonable). Even given that, though, what is the reasoning for marking SVG icons as "Fixed," preventing them from being scaled? Because even when they're scalable they won't work right away as one would imagine. For example, sure, a 64px icon can be downscaled (like in this case) and will be visible at 24px (or 22 or 16) but it won't be clear and sharp like the others that were made at that size. An icon at 64px can be downscaled to 32px with the inconvenience of blurring by the software itself because 1px at 64 isn't 1px at 32; 1px at 64 is half a pixel at 32. On the other hand 1px at 32 is 2px at 64 in which case scaling done by the software works, so scaling only "works" when you take the lowest size and make it bigger and when it's a multiple of that number. But even then the design of the icon has to be adapted to each size. At a bigger size the icon can have more details because there are more pixels to work with like the folders which are both in 32 and 64; or the mimetypes. Then there's the thing that toolbar icons are monochrome. (In reply to Uri Herrera from comment #3) > Because even when they're scalable they won't work right away as one would > imagine. Granted, but an SVG scaled down from 64px to 24px (or probably better yet scaled up from 22px; this could be controlled with intelligent MinSize/MaxSize values in the theme) is going to provide a much better overall user experience than expanding the toolbar by 40 additional pixels. I'm coming to the conclusion that there are (at least) 2 separate issues here. 1. Is virt-manager doing something "wrong" by using the dialog-information icon in a toolbar? One certainly can make the argument that only icons in the action set should be used in a toolbar. OTOH, I don't see anything in the FDO Icon Naming Specification to that effect, so it may not be realistic to expect Gtk applications to adhere to that guideline. Assuming that one accepts the premise that only action icons should be used in toolbars, what icon should virt-manager use to represent the "Show VM details" action? What standard icon should foo use to represent its Frobozulate action? It seems like a fundamentally insoluble problem. So what is an application developer supposed to do when none of the standard action icons makes sense (but one of the *other* standard icons does)? 2. Even if virt-manager is doing something wrong, shouldn't the desktop environment/theme do its best to make it look as good as possible? After all, even if virt-manager is changed, there are always going to be applications out there that don't do things exactly according to the spec. Deliberately uglifying those applications seems like really, really user-unfriendly behavior. (This coming from someone who isn't a virt-manager or Gtk developer and simply wants the applications that he regularly uses to look decent when running in his preferred desktop environment.) MinSize and MaxSize don't do anything different than what I explained. These parameters scale the graphic between the ranges set in them. But they do not alleviate the issues I outlined. > 1. Is virt-manager doing something "wrong" by using the dialog-information icon in a toolbar? Yes. Even when the spec doesn't say "Actions=Toolbar" that's the actual common practice. I've outlined this in the Breeze guidelines too: https://github.com/NitruxSA/breeze-icon-theme/wiki/Icon-naming-and-categorization-guidelines-in-Breeze - for developers to know what icons to put where. > Assuming that one accepts the premise that only action icons should be used in toolbars, what icon should virt-manager use to represent the "Show VM details" action? There's: help-about.svg - essentially the same icon in /actions and meant for the toolbar. > What standard icon should foo use to represent its Frobozulate action? It seems like a fundamentally insoluble problem. > So what is an application developer supposed to do when none of the standard action icons makes sense (but one of the *other* standard icons does)? A developer should 1) request icons for the target environment from a designer or designers (if possible) or 2) do it himself/herself following the target environment guidelines. Virt-manager developers or developer did mostly right by choosing icons from actions for the toolbar with that specific exception. > 2. Even if virt-manager is doing something wrong, shouldn't the desktop environment/theme do its best to make it look as good as possible? It's the applications job to fit within the environment. But since virt-manager is a GTK application I don't (and wouldn't) expect it to fit in Plasma despite Plasma's attempt to theme it. > After all, even if virt-manager is changed, there are always going to be applications out there that don't do things exactly according to the spec. Which is a bad practice. >Deliberately uglifying those applications seems like really, really user-unfriendly behavior. It isn't deliberate. It simply showcases an incorrect usage of icons by some developers. what I don't understand is. we have the status icon dialog-information for breeze in the size 16px, 22px and 64px cause also some kde applications use this icon in the wrong area. so why the 64px icon were downscalled instead of the 22px will be scalled to 24px. As Uri wrote you can't use all icons for everything and when you have monochrome and colored icons you see why. as we have this icon in 22px too I would suggest to add it for 24px cause than it doesn't matter. The best solution would be the solution Uri prefere to change the icon in the application cause than the application has no probem with other icon sets too. Git commit d54ef43f4add1389ab5536ddc6cc3587aced6099 by andreas kainz. Committed on 12/11/2015 at 07:56. Pushed by andreask into branch 'master'. Add 24px dialog-information for GTK apps M +7 -1 icons-dark/index.theme A +347 -0 icons-dark/status/24/dialog-information.svg M +7 -1 icons/index.theme A +346 -0 icons/status/24/dialog-information.svg http://commits.kde.org/breeze-icons/d54ef43f4add1389ab5536ddc6cc3587aced6099 |