GNOME Bugzilla – Bug 644819
New icons with 256x256 included
Last modified: 2012-01-31 23:26:05 UTC
Created attachment 183422 [details] Icons with 'source' and rendering script. New icons with 256x256 size included (very important for shell usage). The svg in the package is only intended to be used to render the icons so it's not to be shipped with the application (only the stuff in hicolor subdir), but it should be kept in the repository since the icons are gpl and it's needed to comply with the source clause. The script is needed to render the icons (it needs inkscape).
Thanks! I noticed that the script is missing any copyright and licence information; but for inclusion in aisleriot it needs to be GPL 3+ (or compatible). Please consult with its author(s) and add an appropriate copyright and licence comment into it. Also, the source .svg is missing a copyright and licence comment too, and has an empty cc:licence property. Finally, the archive only has icons for fixed sizes, missing an icon for the "scalable" category.
Hi, everything is GPL 3+, you don't need to include the rendering script anyway. The icons follow the scheme we use in gnome icon theme, so there's no scalable (scalable is used for symbolic icons nowdays), but we ship huge icons for scaling from 64x64 to 256x256, you should install the icons as in the package.
If the script is GPL 3+, please add a copyright and licence comment into it. I do need to include the rendering script, as per GPL, since the .png files are derived from the source .svg via that script. I know that newer gnome doesn't use "scalable" anymore, but aisleriot still runs on older gnome, which has "scalable". Would it be possible to extract the biggest icon from the .svg as a standalone .svg with a modification to the script, or does inkscape not support that?
Ok, I'll add copyright to the source svg. Really there's no need for scalable.
The high res (256x256px) replaces the former scalable SVG. The amount of detail and the use of effects makes it not viable to install as SVG. There isn't a solid caching mechanism in place and rsvg isn't able to render it accurately and fast currently. If we ever bump into a situation where 256 is not enough, we can raise the bar.
(In reply to comment #4) > Ok, I'll add copyright to the source svg. Really there's no need for scalable. Licence too, please. And to the script. (In reply to comment #5) > The high res (256x256px) replaces the former scalable SVG. The amount of detail > and the use of effects makes it not viable to install as SVG. There isn't a > solid caching mechanism in place and rsvg isn't able to render it accurately > and fast currently. If we ever bump into a situation where 256 is not enough, > we can raise the bar. The future is not the problem. The problem is the past — older gnome versions did use the "scalable" category, and aisleriot still supports those, so a matching "scalable" icon should be available.
Past neither, we are shipping hires since two releases at least. It's compatible with older gnome installs. We cannot install both scalable and 256x256 since it would conflicts.
I don't think you need to include the rendering script at all. You don't embed inkscape in either. You can render the PNGs without using the script just fine. Being th eauthor of the script, you are free to embed the script under the GPL3+ if you insist. It is a trivial launcher of inkscape.
(In reply to comment #6) > > The future is not the problem. The problem is the past — older gnome versions > did use the "scalable" category, and aisleriot still supports those, so a > matching "scalable" icon should be available. gnome-icon-theme does not install a 'scalable' directory for svgs anymore. Old versions of gnome were never showing these huge icons anyway. So it is not really a problem. Looking blurry in gnome-shell _is_ a problem on the other hand, so can we please just fix that ?
(In reply to comment #8) > I don't think you need to include the rendering script at all. You don't embed > inkscape in either. Strawman. We don't need to distribute gcc, libc, etc either, but we do have to dist our Makefile's and configure, for example. The png's are derived from the svg source, so the script is needed, but not distributing inkscape ourself is fine. > Being th eauthor of the script, you are free to embed the script under the > GPL3+ if you insist. It is a trivial launcher of inkscape. Alright, thanks for the clarification. (In reply to comment #9) > > The future is not the problem. The problem is the past — older gnome versions > > did use the "scalable" category, and aisleriot still supports those, so a > > matching "scalable" icon should be available. > > gnome-icon-theme does not install a 'scalable' directory for svgs anymore. Old > versions of gnome were never showing these huge icons anyway. So it is not > really a problem. Hmm, ok. I thought 'scalable' was actually used ... > Looking blurry in gnome-shell _is_ a problem on the other hand, so can we > please just fix that ? Just a few more questions first: - the aisleriot icon is used also 26x26, 34x34, 40x40, 50x50 and 64x50 size for the hildon UI. I guess we could just keep the older icon for that? - aisleriot also uses the 'gnome-freecell' icon name when launched as freecell; do you want to use a) the same icon as aisleriot, b) create a different icon, or c) just keep the old ones (which is missing the 256 size), for that?
Created attachment 183566 [details] Source SVG Here's the 'source' svg with GPL3 reference in the svg metadatas.
Regarding gnome-freecell it sounds silly to me to keep that alias around nowdays (anyway seems like it's not there in F14), I'd just say to kill the alias, but if you want to keep it around use the old icons for it, I have no time (and ideas) for another 256x256 for Gnome 3.
Just to be totally clear: you are the sole author of these icons, and give permission to distribute them under "GPL 3, or (at your option) any later version" ? I ask because the licence now says 3.0; I'd have expected you to add an XML comment with a human-readable copyright and licence stock text. (You don't have to attach an updated file; just confirm the above and I'll add that when adding the file to git.)
Having looked now at the actual artwork, I have some criticisms to make: - the number and suit on the
ace card is just a tiny smudge at these resolutions. - it's a bug that it uses "1"; all our card sets use "A" on the ace cards. - the card background on the 48x48 card has some ugly horizontal lines in the raster. Also in the source code .svg the name is misspelt as 'aislerot'. (Sorry for the split comment; hit a bugzilla bug there!)
For the card, I just copied a set on wikipedia, this one preciselly http://en.wikipedia.org/wiki/File:01_of_hearts_01.svg, I used a 1 istead of A since it's clearer in the smaller sizes. The line is a bloody inkscape bug with patterns, I'll try to see if doing that manually cures it. Sorry for the type. Fixing.
You could just instead copy the card from one of our own card sets [http://git.gnome.org/browse/gnome-games-extra-data/tree/cards]. However any of these cards probably won't render too nice at these tiny sizes :/ An alternative would be to keep the old icons, and just create a new 256x256 icon based on the design of the 48x48 one [http://git.gnome.org/browse/gnome-games/tree/aisleriot/icons/gnome/hicolor_apps_48x48_gnome-aisleriot.png].
Created attachment 183579 [details] Package with rendered icons and svg 'source' Sorry, but I really have no time to draw an hires for that icon, so I sed an "A" in place of the "1" changing various proportions to make it work, fixed rendering problems and also added a comment about the license, since looks like there's a bug in inkscape in license metadata (at least in the UI).
I kept the existing icons for the small sizes, and just added a 256x256 icon in the same style as the 16px one, derived from Paris card theme. Let's call this bug FIXED; if someone wants to design a new, full icon set for all sizes they can open a new bug :)
Christian, I'm confused: why use the Paris theme? It's not the default one used by the game, and the icon in this size is different from the other icons. Although, while I love Paris (that's the card style we have in France :-)), it really doesn't fit the GNOME style for icons...
(In reply to comment #20) > Christian, I'm confused: why use the Paris theme? It's not the default one used > by the game, and the icon in this size is different from the other icons. > > Although, while I love Paris (that's the card style we have in France :-)), it > really doesn't fit the GNOME style for icons... I don't think the new 256 size icon is that different in style from the one proposed in comment 0 here; and also the proposed icons used a different design for the small ones and the big one. The proposed icons were not acceptable at smaller size however (comment 14 and comment 15), and there was also the problem of the missing sizes for aisleriot/hildon (comment 10), the missing freecell icon (comment 10 again), and the missing 'scalable' size icon; and since comment 18 left me with the impression that these issues couldn't be solved before release, I decided to just keep all the smaller-size icons and make up the 256 sized ones myself, copying the cards from one of our themes. I found that at the enormous 256 pixel size, the ace card had simply too much 'empty' white, so I chose to use the J/Q/K cards instead. However, the default Bonded card theme simply looks like crap at that size, which is why I used the cards from the Paris theme. (I'd *love* to make Paris the default; Bonded is simply default because it loads faster.) I'm open to changing the icons, but any new icons suite I could accept would need to address all the problems I mentioned above.
(In reply to comment #21) > (In reply to comment #20) > > Christian, I'm confused: why use the Paris theme? It's not the default one used > > by the game, and the icon in this size is different from the other icons. > > > > Although, while I love Paris (that's the card style we have in France :-)), it > > really doesn't fit the GNOME style for icons... > > I don't think the new 256 size icon is that different in style from the one > proposed in comment 0 here; and also the proposed icons used a different design > for the small ones and the big one. The proposed icons were not acceptable at > smaller size however (comment 14 and comment 15), and there was also the > problem of the missing sizes for aisleriot/hildon (comment 10), the missing > freecell icon (comment 10 again), and the missing 'scalable' size icon; and > since comment 18 left me with the impression that these issues couldn't be > solved before release, I decided to just keep all the smaller-size icons and > make up the 256 sized ones myself, copying the cards from one of our themes. > > I found that at the enormous 256 pixel size, the ace card had simply too much > 'empty' white, so I chose to use the J/Q/K cards instead. However, the default > Bonded card theme simply looks like crap at that size, which is why I used the > cards from the Paris theme. (I'd *love* to make Paris the default; Bonded is > simply default because it loads faster.) > > I'm open to changing the icons, but any new icons suite I could accept would > need to address all the problems I mentioned above. I understand the frustration with this being so late. I postponed an icon update myself for lack of time. But the new 256px icon is actually both an unapproved UI freeze break and actually a step backward, style-wise, from the scaled-up, blurry icon that Shell was showing until this was merged. I think, at the very least, we should revert the new icon. I'm actually happy with the new icon but can see your point about it not reflecting one of our themes. Let's try and do something better for 3.0.1 which will actually be out before any distro. ships GNOME 3?
(In reply to comment #22) > I understand the frustration with this being so late. I postponed an icon > update myself for lack of time. But the new 256px icon is actually both an > unapproved UI freeze break I don't see how adding a new icon has anything to do with UI freeze, esp. if that icon will only ever be displayed in one place (the shell) ? Anyway, looking at r-t ML, it appears that 256px icons additions are just being approved without problems, so I don't see why this one would be different. > and actually a step backward, style-wise, from the > scaled-up, blurry icon that Shell was showing until this was merged. Now _that_ is not true — scale up the 48px icon to 256px and it looks like arse :) > I think, > at the very least, we should revert the new icon. I don't really see anything wrong with the icon, but if you really prefer to blurry 48px scaled up, you can revert by just removing the new icons from aisleriot/icons/gnome/Makefile.am on the gnome-3-0 branch (or master, and revert after branching).
I consider this a blocker, personally. Another option would be to remove aisleriot from the release...
Matthias: Not really.
Sorry I lost track of this one, I can quickly make the ace reflect the current bonded theme, I see no point in using a jack (it will look bad in smaller sizes, and I really see no poin in using a jack in hires and an ace in the other). I can understand your concerns for hildon, but from what I see you currently have no icons for these sizes with the current stuff. For the svg as explained it's not needed and we have no way to 'cut' the svg out of the one-canvas sheet so we'll need to change the workflow and I prefer not to do that. For hildon stuff we can do something as we do for the 24x24 which is actually the 22x22 + 1 px empty frame, since the sizes needed aren't so different the resulting size icons won't look bad. For gnome freecell sorry, I have no time for another icon, anyway I think it's not needed, really. I'll attach a new package asap, in case you'll want to use it.
Created attachment 184679 [details] icons + source
(In reply to comment #26) > Sorry I lost track of this one, You didn't lose track; I simply had fixed the bug differently, so there was nothing to track anymore. > I can quickly make the ace reflect the current > bonded theme, I see no point in using a jack (it will look bad in smaller > sizes, and I really see no poin in using a jack in hires and an ace in the > other). The point is as I said in comment 21: it's too much empty white. If you're going to make a huge 256px icon, why not take advantage and include some nicely detailed graphics? I don't think the difference in the design to the smaller icons matters, since even in your original proposal they used a different scheme. > I can understand your concerns for hildon, but from what I see you > currently have no icons for these sizes with the current stuff. aisleriot/icons/hildon/ has a full set of icons. > For the svg as > explained it's not needed and we have no way to 'cut' the svg out of the > one-canvas sheet so we'll need to change the workflow and I prefer not to do > that. That's just a technical problem to be solved, and not a reason not to do it at all. > For hildon stuff we can do something as we do for the 24x24 which is > actually the 22x22 + 1 px empty frame, since the sizes needed aren't so > different the resulting size icons won't look bad. Right, that's how these icons were produced for the 26,32 and 50 sizes. > For gnome freecell sorry, I > have no time for another icon, anyway I think it's not needed, really. Well, _I_ think it's needed; and I'm not going to accept an icon for aisleriot without a matching one for freecell.
I feel this is not about icons, but something else, I call myself out, sorry guys.
I am really sad about this bug. The icon chpe glued together really lacks in execution and feels totally out of place with all the rest of work we have done for 2.8 and 3.0. A strong outline, a saturated color palette, lack of whitespace and essentially every point of the guidelines* are ignored. It's a raised finger to all the unification and polish effort we have put in.
* http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines
Lapo, thanks for making the requested change. I'm going to defer to our artists whose work and opinion I respect and merge lapo's latest contribution. I'm going to take the r-t member comments on this bug as a freeze break approval. chpe, please feel free to change anything that I do in a way which only applies to hildon.
Let's not get sidetracked with the hildon icon set; this is *not* just (or even *mostly*) about hildon. See comment 21 for a list of _all_ the problems with the proposed icon set. The attached icon set still doesn't address *any* of my points; just committing it is not acceptable. Since you seem to think the scaled-up 48px icon looks better than the new one (comment 22), I'd say to just not dist the new 256px ones at all (comment 23), and try again for 3.2 .
Ok, can we than get a tarball with asleriot disabled by default, please ? Sad that its coming to this...
No. If r-t really does consider the original addition of a new icon size to the installed icon a UI freeze break, all they can get is a revert of that patch. I have done that in git; the 256px icons aren't installed nor disted anymore. However I don't see that r-t has any power to force the module to change its configure options defaults, and I really angry about how you're trying to bully me into just accepting an icon set I don't think is adequate.
Created attachment 184706 [details] [review] aisleriot: Add new 256 px size icons Take the existing scalable aisleriot and freecell icons, change their size to fill the whole 256 px and render them to png using rsvg-convert. Bug #644819.
How about this: above patch takes the existing 'scalable' icons, changes the svg to produce 256px full-size icons and renders them to png. So they look exactly like the existing 48px icons, just at 256px without any blurring.
Created attachment 184714 [details] [review] aisleriot: Add new 256 px size icons Take the existing scalable aisleriot and freecell icons and render them at 256px using rsvg-convert (zoom factor 256/48). Bug #644819.
Rendering the icon into a 256x256px canvas doesn't really work. While it may not be blurry, the feel of the icon is completely different to what we have everywhere else. The stroke of the icon including the inner highlight become the dominant feature, making it look very stylized/cartoony. The icon targeting a 48x48px canvas lacks all the detail that is featured on the 'highres' icons we have produced since 2.3x.
http://people.gnome.org/~chpe/images/hicolor_apps_256x256_gnome-aisleriot.png http://people.gnome.org/~chpe/images/hicolor_apps_256x256_gnome-freecell.png
I have made my decision clear. Please do not touch the tree again until I commit Lapo's icons.
Please consider the above patch instead of the 'lapo' icon set (the smaller icons in there look really bad). Despite what comment 39 says, the existing scalable icons render just fine at 256px (see comment 40) and fit with the existing artwork.
I disagree on all three points.
The following fixes have been pushed: 8fe03e7 aisleriot: Use GNOME Design Team's new icon with 256x256 size 7f3606c Revert "aisleriot: icons: Add 256 size freecell app icon" 5542e28 Revert "build: aisleriot: Don't dist the 256px size icons" 0bb5d3c Revert "aisleriot: icons: Make 256 size aisleriot and freecell icons more similar" e94d204 Revert "aisleriot: Crush PNG files"
Created attachment 184720 [details] [review] aisleriot: Use GNOME Design Team's new icon with 256x256 size A new Freecell icon is not yet ready so continue to install those.
Created attachment 184721 [details] [review] Revert "aisleriot: icons: Add 256 size freecell app icon" This reverts commit e97f6156918058441a19b4232244e144981c2760.
Created attachment 184722 [details] [review] Revert "build: aisleriot: Don't dist the 256px size icons" This reverts commit 47542081ae052fb1b66fd0246e9691ae9850f858.
Created attachment 184723 [details] [review] Revert "aisleriot: icons: Make 256 size aisleriot and freecell icons more similar" This reverts commit ebac2e77620ce2b1d8dccb25fe10337fa1bb5a7e.
Created attachment 184724 [details] [review] Revert "aisleriot: Crush PNG files" This reverts commit 65a5a49989edcfd217d1170d0270177a897d214c.
I don't really have an opinion about the icons themselves. I do however have issues with the way the decision was made here. The defacto maintainer of aisleriot is unquestionably chpe. He has been the main developer and decision maker for that game for years. Overruling him with the authority as (largely inactive) module co-maintainer feels like power abuse. I would have been very demotivated by this and I don't think we want to do that to our main developer. Time to reconsider splitting up gnome-games?
(In reply to comment #50) > Time to reconsider splitting up gnome-games? I already proposed and we agreed on just that in a private email exchange. Let's take any further discussion of that proposal to games-list though *after* GNOME 3.0 is out. I *really* didn't want to spend two hours on this today.
Created attachment 184751 [details] alternative version implementing most of Christian requirements I implementented most of your requirements (no there's no svg, since it's not usefull and it uses a there's an ace - mimicking the bonded theme - in all version, having very different version may be misleading), I'm the sole author and it's licensed GPL3+. now please stop all this mess.
(In reply to comment #52) > Created an attachment (id=184751) [details] > alternative version implementing most of Christian requirements > > I implementented most of your requirements (no there's no svg, since it's not > usefull and it uses a there's an ace - mimicking the bonded theme - in all > version, having very different version may be misleading), I'm the sole author > and it's licensed GPL3+. now please stop all this mess. Christian, if you feel that these are an improvement and more in line with what you had in mind, I would be happily to merge the new versions. Just let me know and I'll handle the work.
This bug is being reassigned to the "general" component so we can close the aisleriot bugzilla component. Apologies for the mass email!