worms invasion wrote:
Well, re. the proposed Tango icon set for Inkscape... I do NOT want to be "forced" to test the Tango icons - let alone to be forced to use them. I hate the Tango icons. :-)
The same argument that Tango people has: We hate that set, we don't want to be forced to that.
The main reasons are:
- they are unreadable, "undecodable".
I do not need to use a magnifying glass to "decode" the current (non Tango) icon set, the icons are "sharp" and "clear". Compared to them, the Tango icons are... "wtf?... which icon is that...?" I do not want to lose time wondering each time I need to click on an icon (and it happens quite a lot in Inkscape, because I don't use the shortcuts or F-keys). Honestly, I hardly *see* the Tango icons.
Some of the current Tango icons need some contrast tweaking, that's right. Plus the non-black outlines give less contrast than black lines, but the problem with black and dark/black themes is an issue. Anyway, I don't think they are unreadable, undecodeable or that you need a magnifying glass to see them.
- they belong to the Linux world.
They're intended to be multi-platform. Just as Inkscape and other free applications. Using an icon set created for that purpose is consistent to a free, open source, multi-platform program. Other people can argue that free software belongs to linux world and you shouldn't use it in Windows :-)
- I do not use any other "free" software which uses the Tango icon set, such as The Gimp or..., so I don't care about "being used" to seeing such or such icons.
That's your point of view. You don't care, and since it's not your concern you don't consider if others do. I don't want to bring such discussion to the list, but I'd like to know why people is using inkscape? Just because it's free of charge? It's also free (libre) software, and a lot of people cares about that. Being part of a software movement that's created in a collaborative way implies to have a goal and work to make it happen. There are people who sees inkscape just as an application that costs nothing, but others see it as a part of something bigger. Theme changers are quite common in shareware/freeware apps for windows, so I don't think that would be a big deal if we put Tangos as default and let people change it back to the current set if they don't like it. That would be enough for them (they won't be forced to Tango) and would be nice for people who prefers Tango because they fit with the other free apps.
In my honest opinion, for people who sees inkscape as a freebie, a UI option for changing the icon set will be enough.
I don't want to make a political discussion about this, and I'm not saying that you are that kind of people (i can't speak, I don't know).
- I believe each application can have its own style, its own icons. I hate the "applications on a platform must all look alike" concept, it's sterile, it's boring, it's dull.
Of course, and nobody denies that, and that's why we need an easy way to change icon themes from the preferences. You're talking about what you hate and what you'd love, what would be amusing, bright and happy and not a technical reason. People who back up Tango icons ask them to be default for technical reasons, not just personal preferences -A normalized icon set with clear design guidelines -More care about details (pixel alignment, for instance) -An unified look between free design applications -Better look in dark gtk themes.
If the current set would cover most of these topics (well, the unified look with other apps wouldn't be possible) I bet most of the Tango people would find it acceptable and a easy icon theme changer in the preferences would suffice.
So, my user opinion is: if the Linux users are masochists and want to have Tango style icons for Inkscape, fine, give them a GUI to switch to Tango icons.
Again, just change the "Linux" word for "Windows" and change the Tango word for "current" and that's the way I see it. This is matter of personal taste. I'd prefer to talk about technical reasons.
Gez.
Guillermo Espertino <gespertino@...360...> writes:
Theme changers are quite common in shareware/freeware apps for windows, so I don't think that would be a big deal if we put Tangos as default and let people change it back to the current set if they don't like it. That would be enough for them (they won't be forced to Tango) and would be nice for people who prefers Tango because they fit with the other free apps.
I love the tango theme but I appreciate the fact that key developers think otherwise. Perhaps the attitude Inkscape should adopt is the same as Firefox and OpenOffice and have different distro-specific default themes. In both these apps, the default icon theme is different on different OSs. Tango can be the default on Ubuntu, while the current theme can be the default on standalone installers such as autopackage or windows.
Guillermo Espertino wrote:
Theme changers are quite common in shareware/freeware apps for windows, so I don't think that would be a big deal if we put Tangos as default and let people change it back to the current set if they don't like it. (...) In my honest opinion, for people who sees inkscape as a freebie, a UI option for changing the icon set will be enough.
No, no, no! This only makes some sense on Windows. On Linux we already have the GTK icon theme mechanism. We don't need a theme changer like OO.o (which is an outstanding example how not to do cross platform desktop integration). We need this:
http://live.gnome.org/ThemableAppSpecificIcons
We can also have a different icon set on Windows. I think I will work on implementing this before tearing apart the extension system to add GIO support. The old icons will be embedded in the application, while the new Tango icons will be installed in /usr/share/inkscape/icons/hicolor. This way everyone will be happy including me (I am maintaining Gartoon Redux).
Regards, Krzysztof Kosiński
OK, I have started to work on Inkscape themability. The first task will be to separate the icons from icons.svg into separate files. I put the first portion of icons in share/icons/hicolor/scalable.
Does anyone know whether Gdk-Pixbuf on Windows supports SVG? If it did, it would make everything easier, but if it doesn't, it just means I'll need to create some PNG renders.
Regards, Krzysztof Kosiński.
On Feb 9, 2009, at 8:08 PM, Krzysztof Kosiński wrote:
OK, I have started to work on Inkscape themability. The first task will be to separate the icons from icons.svg into separate files. I put the first portion of icons in share/icons/hicolor/scalable.
Does anyone know whether Gdk-Pixbuf on Windows supports SVG? If it did, it would make everything easier, but if it doesn't, it just means I'll need to create some PNG renders.
Please don't just split them out.
Instead look at the existing mechanisms for named icons. GTK+ has a whole infrastructure for that already.
2009/2/10 Jon A. Cruz <jon@...18...>
Please don't just split them out.
Instead look at the existing mechanisms for named icons. GTK+ has a whole infrastructure for that already.
Maybe I'm wrong but why not using specifications from http://icon-theme.freedesktop.org/wiki/HicolorTheme ?
I know that the parsing code of the icons.svg file already exist in inkscape sources and that it's easier to design an icon theme when all of them are in the same svg file.
And I know too that it's a pain to do some changes in scalable icons of a theme as you have to open all svg files to edit one gradient for example.
So my proposal is : Why not creating an extension for Inkscape that will automatically create the scalable folder (with action,devices,emblems, etc. folders) from a single svg file ?
Hi,
looks looks Jimmac has an interesting work flow: http://jimmac.musichall.cz/log/?p=436/
Regards, Tobias
On Tue, Feb 10, 2009 at 8:58 AM, Yann Papouin <yann.papouin@...400...> wrote:
2009/2/10 Jon A. Cruz <jon@...18...>
Please don't just split them out.
Instead look at the existing mechanisms for named icons. GTK+ has a whole infrastructure for that already.
Maybe I'm wrong but why not using specifications from http://icon-theme.freedesktop.org/wiki/HicolorTheme ?
I know that the parsing code of the icons.svg file already exist in inkscape sources and that it's easier to design an icon theme when all of them are in the same svg file.
And I know too that it's a pain to do some changes in scalable icons of a theme as you have to open all svg files to edit one gradient for example.
So my proposal is : Why not creating an extension for Inkscape that will automatically create the scalable folder (with action,devices,emblems, etc. folders) from a single svg file ?
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Jon A. Cruz wrote:
Please don't just split them out.
Instead look at the existing mechanisms for named icons. GTK+ has a whole infrastructure for that already.
I know that :) However, to use the theming mechanism I have to split them off anyway, becuase as far as I can tell it doesn't support using fragments of SVG as named icons.
With regards to the HicolorTheme mechanism, it has problems: 1. We ship some icons which are present in all Gnome installations but not on Windows (e.g. the icons to rotate and flip an object). Putting those in hicolor could cause us to overwrite some files which were already there (or, actually, fail to install, because dpkg protects against overwrites). 2. Those icons would be visible to all apps and override their own app-specific icons. We don't want this. 3. It's not clear where the hicolor theme is located on Windows. With ThemableAppSpecificIcons we specify the path ourselves, so it is not a problem.
PS I'm mostly following the icon names specified in Tango's ArtLibreSet, but many of our icons don't have equivalents there, and the set seems to have duplicate icon names (e.g. boolean-union and path-union - I chose the latter).
Regards, Krzysztof Kosiński
On Feb 10, 2009, at 5:40 AM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
Please don't just split them out.
Instead look at the existing mechanisms for named icons. GTK+ has a whole infrastructure for that already.
I know that :) However, to use the theming mechanism I have to split them off anyway, becuase as far as I can tell it doesn't support using fragments of SVG as named icons.
No, we don't. We'd only have to split things out if we let the system use it's file-based approach. That has many problems.
*However*, GTK+ supports all the calls needed for the application itself to be a source of named icons. We need to finish all the details of using it, but the main code is in Inkscape now.
So Inkscape itself becomes a provider of named icons. Then it also uses the named icon access calls. Therefore, if the system *does* get some overriding theme installed, Inkscape will respect that today.
PS I'm mostly following the icon names specified in Tango's ArtLibreSet, but many of our icons don't have equivalents there, and the set seems to have duplicate icon names (e.g. boolean-union and path-union - I chose the latter).
That's probably the number one thing we have to do.
1) determine which names in Inkscape are covered in Art Libre. 2) list any issues of complicated names. 3) determine which need to be added to Art Libre.
That was the whole reason for the Art Libre names to begin with.
(btw, be sure to look at the *logical* icon representations, not the *physical*.)
I didn't expect this to generate so much interest :)
Jon A. Cruz wrote:
No, we don't. We'd only have to split things out if we let the system use it's file-based approach. That has many problems.
It also has one big advantage, namely you don't have to dig in the source code to discover which icon names you need to provide in your theme. The monolithic icons.svg file is also fairly unobvious to theme designers.
*However*, GTK+ supports all the calls needed for the application itself to be a source of named icons. We need to finish all the details of using it, but the main code is in Inkscape now.
I can't find the relevant GTK extension point. I think you are talking about gtk_icon_theme_add_builtin_icon(), but it's not documented whether the built-in icons sort in the lookup order after or before icons from the theme (we want them after theme icons).
That's probably the number one thing we have to do.
- determine which names in Inkscape are covered in Art Libre.
- list any issues of complicated names.
- determine which need to be added to Art Libre.
I used their names where it made sense, but I also changed some of them. Their wiki seems to be invitation-only - does anybody here have edit access?
Aaron Spike-2 wrote:
- Dogfood. People wanted to use our renderer for the icons as a visual
test and because other renderers weren't up to par.
We can use Inkscape's shell mode to render the icons at build time. It would be a matter of generating / writing a simple script.
- Startup time. IIRC startup times were shown to be significantly
faster loading icons from a single file.
I intend to render to PNG at build time, so it would be even faster than rendering all the icons at startup. An additional benefit is that if the icon is overridden in the user's icon theme, it will load from the icon cache, which is blazingly fast.
- Convenience for icon designers. Being able to look over a whole theme
and judge consistency and share gradients and such was a huge benefit. So I'm sure people would be happy if there was a workflow for generating the individuals from the composite.
I think that an automated export of SVG fragments + build-time PNG render is better than using the big file at runtime. We can distribute a script that will extract groups with IDs corresponding to the icon names and create discrete SVGs as well as PNG renders.
Probably I wasted some effort on manually extracting all the icons from icons.svg, but at least we'll have a naming reference for now. Inkscape could be used to extract the icons from icons.svg, but the --export-id option doesn't work with --export-plain-svg, and there is no --export-svg option (which would export Inkscape SVGs).
Regards, Krzysztof Kosiński
On Tue, Feb 10, 2009 at 3:21 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
I didn't expect this to generate so much interest :)
I could not help wondering about that, too. I'm not trying to decide for others, but honestly, I think it's way too much effort spent on fixing something which is not broken. There's so much urgent work on functionality and bugs... can't we just switch to tango (have we agreed on that?) and leave the icons stuff alone? It works just fine IMHO.
2009/2/10 bulia byak <buliabyak@...400...>:
On Tue, Feb 10, 2009 at 3:21 PM, Krzysztof Kosiński <tweenk.pl@...1063....> wrote:
I didn't expect this to generate so much interest :)
I could not help wondering about that, too. I'm not trying to decide for others, but honestly, I think it's way too much effort spent on fixing something which is not broken. There's so much urgent work on functionality and bugs... can't we just switch to tango (have we agreed on that?) and leave the icons stuff alone? It works just fine IMHO.
Agree completely, theres gotta be higher priorities to work on than this...
On 02/10/2009 04:07 PM, bulia byak wrote:
On Tue, Feb 10, 2009 at 3:21 PM, Krzysztof Kosiński<tweenk.pl@...400...> wrote:
I didn't expect this to generate so much interest :)
I could not help wondering about that, too. I'm not trying to decide for others, but honestly, I think it's way too much effort spent on fixing something which is not broken. There's so much urgent work on functionality and bugs... can't we just switch to tango (have we agreed on that?) and leave the icons stuff alone? It works just fine IMHO.
+1
Cheers, Josh
bulia byak wrote:
I could not help wondering about that, too. I'm not trying to decide for others, but honestly, I think it's way too much effort spent on fixing something which is not broken.
You know, I'm a theme author as well, and I can't theme Inkscape - in this respect it's broken :) A better icon theme doesn't add features, but it is an important factor contributing to the application's perceived quality. Xsane has awful icons, and looks like like a low quality application because of this.
Regards, Krzysztof Kosiński
On Tue, Feb 10, 2009 at 8:02 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
You know, I'm a theme author as well, and I can't theme Inkscape - in this respect it's broken :) A better icon theme doesn't add features, but it is an important factor contributing to the application's perceived quality. Xsane has awful icons, and looks like like a low quality application because of this.
OK, like I said, I'm not going to tell you what to work on - everyone has his own interests. I just want to add my voice to those who are against breaking icons.svg into smithereens (I noticed you already started that!) - it will be a terrible thing for icon authors and, I'm sure, for program load time.
Also, after your changes to configure.ac I get:
checking for INKSCAPE... configure: error: Package requirements (gdkmm-2.4 glibmm-2.4 gtkmm-2.4 >= 2.10.0 gtk+-2.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 cairo sigc++-2.0 >= 2.0.12 gtkspell-2.0 gthread-2.0 >= 2.0 libpng >= 1.2 gsl giomm-2.4) were not met:
No package 'giomm-2.4' found
Do you really need this new lib? If it wasn't intentional I'd appreciate reverting this, as right now I have very little time to find, compile and install it. In any case, I think we have something of a policy to discuss new dependencies before adding them.
2009/2/10 bulia byak <buliabyak@...400...>:
No package 'giomm-2.4' found
Note: I just removed this requirement from configure, and got no errors in compiling, linking, or running.
bulia byak wrote:
2009/2/10 bulia byak <buliabyak@...400...>:
No package 'giomm-2.4' found
Note: I just removed this requirement from configure, and got no errors in compiling, linking, or running.
giomm-2.4 is a dependency of new versions of gtkmm. I have GTK 2.14 and without this it doesn't compile. Normally I kept this in my version of configure.ac but this time I forgot to remove it before committing. I'll try to add some conditional code to include giomm-2.4 only if gtkmm requires it.
Regards, Krzysztof Kosiński
bulia byak wrote:
OK, like I said, I'm not going to tell you what to work on - everyone has his own interests. I just want to add my voice to those who are against breaking icons.svg into smithereens (I noticed you already started that!) - it will be a terrible thing for icon authors and, I'm sure, for program load time.
I'll add a script that generates the icons from icons.svg or a compatible file. For now I committed the discrete icons so that others could suggest name changes while I'm at an early stage and they aren't used anywhere in the code. There will also be PNG renders, so the load time could actually improve (I think it's much faster to load 300 PNG files than to load one big file and render 300 pixmaps).
Regards, Krzysztof Kosiński
On Feb 10, 2009, at 7:51 PM, Krzysztof Kosiński wrote:
I'll add a script that generates the icons from icons.svg or a compatible file. For now I committed the discrete icons so that others could suggest name changes while I'm at an early stage and they aren't used anywhere in the code. There will also be PNG renders, so the load time could actually improve (I think it's much faster to load 300 PNG files than to load one big file and render 300 pixmaps).
I think a much better approach to tackle the names is to get a page going on the Wiki. A simple table can do wonders.
Also let me know if you might be interested in some XSLT to track and process such items.
i *strongly* feel that getting the names cleaned up will be a *huge* win. Aside from the "blurry icon" issue, that's a main one left in this area.
On Feb 10, 2009, at 4:02 PM, Krzysztof Kosiński wrote:
You know, I'm a theme author as well, and I can't theme Inkscape - in this respect it's broken :) A better icon theme doesn't add features, but it is an important factor contributing to the application's perceived quality. Xsane has awful icons, and looks like like a low quality application because of this.
But as of post-0.46 changes, you *can* theme Inkscape. It first and foremost looks to the system for icons, and only uses its internal ones if no system ones are present for that name.
On Feb 10, 2009, at 11:21 AM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
No, we don't. We'd only have to split things out if we let the system use it's file-based approach. That has many problems.
It also has one big advantage, namely you don't have to dig in the source code to discover which icon names you need to provide in your theme. The monolithic icons.svg file is also fairly unobvious to theme designers.
There are many other ways to approach this.
One would be a simple XSLT run on the icons.svg to generate a list of icons. Other things could be done, but that one might be the simplest and most web-developer friendly.
And for a generic theme designer out there, Inkscape will happily go with any icons they've added in a standard themeing way. The single file is more for the Inkscape internal/built-in icons.
*However*, GTK+ supports all the calls needed for the application itself to be a source of named icons. We need to finish all the details of using it, but the main code is in Inkscape now.
I can't find the relevant GTK extension point. I think you are talking about gtk_icon_theme_add_builtin_icon(), but it's not documented whether the built-in icons sort in the lookup order after or before icons from the theme (we want them after theme icons).
GtkIconTheme GtkIconTheme — Looking up icons by name http://library.gnome.org/devel/gtk/stable/GtkIconTheme.html
"Themeable Stock Images" is another, but not the main thing we want.
Did you check what the calls do? They do look to the system first, and then go to the internal as a fall-back. Try switching icon themes for the system and watch which icons change in our UI and which do not. Then look at a few of those changing ones to see what they are named. That should be a good starting point.
That's probably the number one thing we have to do.
- determine which names in Inkscape are covered in Art Libre.
- list any issues of complicated names.
- determine which need to be added to Art Libre.
I used their names where it made sense, but I also changed some of them. Their wiki seems to be invitation-only - does anybody here have edit access?
Just jump on #tango at freenode sometime. They've been quite helpful, and I've been working on and off with them for a while now.
Aaron Spike-2 wrote:
- Dogfood. People wanted to use our renderer for the icons as a
visual test and because other renderers weren't up to par.
We can use Inkscape's shell mode to render the icons at build time. It would be a matter of generating / writing a simple script.
Yes. Especially one that was used as an extension also.
- Startup time. IIRC startup times were shown to be significantly
faster loading icons from a single file.
I intend to render to PNG at build time, so it would be even faster than rendering all the icons at startup. An additional benefit is that if the icon is overridden in the user's icon theme, it will load from the icon cache, which is blazingly fast.
That won't work. With the fact that things can scale, you'd need to generate dozens of PNG versions for each SVG version.
Hi!
I just do not get, why we cant *reference* separate .svg files from a main one. So it looks like, we have all icons in a single svg document (so easy for the designers), but in reality it does not contains all the icons but references them. So when editing it edites the referenced .svg file.
With this setup we could have each icon in a separate .svg file, and we could also have a main .svg document which displays all of them.
I do not know what is the most standard compliant way to implementing it, maybe the <image> element?: http://www.w3.org/TR/SVG/struct.html#ImageElement
It would be useful for many usecases, like drawing a schematic, where each symbols located in different files. (Im using inkscape for drawing power electricity, but for now I copy the symbols, the safest way.)
Best regards, Khiraly
On Wed, Feb 11, 2009 at 5:49 AM, Jon A. Cruz <jon@...18...> wrote: et the system
use it's file-based approach. That has many problems.
It also has one big advantage, namely you don't have to dig in the source code to discover which icon names you need to provide in your theme. The monolithic icons.svg file is also fairly unobvious to theme designers.
There are many other ways to approach this. One would be a simple XSLT run on the icons.svg to generate a list of icons. Other things could be done, but that one might be the simplest and most web-developer friendly. And for a generic theme designer out there, Inkscape will happily go with any icons they've added in a standard themeing way. The single file is more for the Inkscape internal/built-in icons.
Jon A. Cruz wrote:
But as of post-0.46 changes, you *can* theme Inkscape. It first and foremost looks to the system for icons, and only uses its internal ones if no system ones are present for that name. (...) And for a generic theme designer out there, Inkscape will happily go with any icons they've added in a standard themeing way. The single file is more for the Inkscape internal/built-in icons.
I think you mean that you can replace icons.svg in your home directory. This is not what I mean by "theming". I mean being able to replace the icons used in Inkscape simply by putting an appropriately named icon in my icon theme. Inkscape doesn't look in the current theme for anything except the three "legacy icons" specified in widgets/icon.cpp.
Also let me know if you might be interested in some XSLT to track and process such items.
Yes, some help on the front of automatically creating discrete SVG icons from the monolithic file could help. I planned to modify Inkscape's command line functionalities to provide this, but using an XSLT would be a better idea. The main problem is that icons.svg uses a lot of clones, but maybe they aren't such a problem in XSLT.
Did you check what the calls do? They do look to the system first, and then go to the internal as a fall-back. Try switching icon themes for the system and watch which icons change in our UI and which do not. Then look at a few of those changing ones to see what they are named. That should be a good starting point. If the builtin is only used as a fallback, then it's OK. But there's another thing: gtk_icon_theme_add_builtin_icon takes a GdkPixbuf, so effectively this is the same as using PNGs, but in the latter case they wouldn't have to be rendered at startup.
BTW, The "blurry icon issue" is caused by toolbars using 18x18 icons, which aren't standard, and the icons in icons.svg being designed for viewing at 16x16.
Regards, Krzysztof Kosiński
On Feb 11, 2009, at 4:15 PM, Krzysztof Kosiński wrote:
I think you mean that you can replace icons.svg in your home directory. This is not what I mean by "theming". I mean being able to replace the icons used in Inkscape simply by putting an appropriately named icon in my icon theme. Inkscape doesn't look in the current theme for anything except the three "legacy icons" specified in widgets/icon.cpp.
No, I meant proper themeing as promoted by the artists and techs behind Tango among other things.
Inkscape looks to the theme for many icons. If it's not looking for all, then it's only because some code has been waiting for themers to test. The "legacy icons" are actually special cases where there is a name used by themes that does not match the older name used internally by Inkscape. However, if we were to just switch them then existing icons.svg files would stop working, etc. So code was added to fall-back for those legacy cases.
Looking at my current OS X config, I see eleven of the twenty-five I see on my main toolbar are ones that come from my local theme.
Also let me know if you might be interested in some XSLT to track and process such items.
Yes, some help on the front of automatically creating discrete SVG icons from the monolithic file could help. I planned to modify Inkscape's command line functionalities to provide this, but using an XSLT would be a better idea. The main problem is that icons.svg uses a lot of clones, but maybe they aren't such a problem in XSLT.
Oh, I was mainly thinking of creating tables listing icons and names for comparisons, etc. If you want to actually end up with SVG files, and not PNG exports, you should just look at verbs and the "--shell" option.
If the builtin is only used as a fallback, then it's OK. But there's another thing: gtk_icon_theme_add_builtin_icon takes a GdkPixbuf, so effectively this is the same as using PNGs, but in the latter case they wouldn't have to be rendered at startup.
No, it's a bit different. The existing code is even in there that tracks things as needed. Among other behavior, it tracks what sizes things are going to be showed at and then does a just-in-time rendering at the needed size so that when the theme asks for the specific name and size it gets that. And since this is done dynamically at run-time, things can adjust on-the-fly as the user changes options on their current environment.
We also added some code a while back that does icon rendering on a background callback. That way the only real delay is for rendering the icons that are shown initially. Anything that is under a menu or on a different page or toolbar, etc. will be delayed and rendered as you're distracted by other things.
BTW, The "blurry icon issue" is caused by toolbars using 18x18 icons, which aren't standard, and the icons in icons.svg being designed for viewing at 16x16.
No. That's not the main "burry icon issue". I had been told that in the past, but when I turned on the debugging option that puts a grid of dots on all Inkscape rendered icons, I saw that the dots (single pixels) themselves blurred out. So there are really two blur issues, with the pixmap-is-wrong-sized being the far more corrupting one.
Of course a lot of this depends on the current OS you are running on, the current desktop involved, and the particular themes. Ubuntu has some more problems, since their default theme has many items with different logical sizes end up the same physical size.
Jon A. Cruz wrote:
The "legacy icons" are actually special cases where there is a name used by themes that does not match the older name used internally by Inkscape.
I am 100% sure those are the only icons looked up in the theme, because I tested it.
Looking at my current OS X config, I see eleven of the twenty-five I see on my main toolbar are ones that come from my local theme.
You are probably confusing GTK stock item theming with application theming. Inkscape uses some icons from the current theme because it uses GTK stock items. The icons used for e.g. the tool switcher ar not themed.
Oh, I was mainly thinking of creating tables listing icons and names for comparisons, etc. If you want to actually end up with SVG files, and not PNG exports, you should just look at verbs and the "--shell" option.
A table with icon names is a good idea. I'll create renders and a nice table and put it somewhere on the wiki.
No, it's a bit different. The existing code is even in there that
tracks things as needed.
I referred to the approach where we do the following: 1. Add all our icons using gtk_icon_theme_add_builtin_icon upon startup 2. Query the theme for any icons we need This would need all icons to be pre-rendered before the start. However, your post gave me another idea. We might add the builtin icons lazily, e.g. when we find an icon which doesn't exist in the theme. Ideally I would want a fallback order like this: 1. Query the icon in the current theme, looking for any size 2. Query the icon in PNG prerenders, looking for an exact size 3. Render from icons.svg and add as a builtin icon, after which all further attempts to load this icon would end at 1 (GtkIconTheme would return the icon we have rendered) However, this requires changing the search path after the first query, and I don't know how it would affect startup performance.
when I turned on the debugging option that puts a grid of dots on all Inkscape rendered icons, I saw that the dots (single pixels) themselves blurred out.
Were those put on the SVG canvas as 1x1 rects, or on the renders? If the latter is true, then that's weird. I think there might be a mixup in the relation between logical and physical sizes somewhere in sp_icon_get_phys_size.
Regards, Krzysztof Kosiński
On Feb 12, 2009, at 4:50 PM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
The "legacy icons" are actually special cases where there is a name used by themes that does not match the older name used internally by Inkscape.
I am 100% sure those are the only icons looked up in the theme, because I tested it.
Looking at my current OS X config, I see eleven of the twenty-five I see on my main toolbar are ones that come from my local theme.
You are probably confusing GTK stock item theming with application theming. Inkscape uses some icons from the current theme because it uses GTK stock items. The icons used for e.g. the tool switcher ar not themed.
You probably need to set up a wiki page and list exactly which theme mechanisms on which platforms you tested.
I know that as I was exercising the code, I tried many different themes, including adding new names to existing themes, and those worked for me.
I remember testing both stock items *and* named icons, and seeing positive results for both.
I did not try any of the new "application theme" idea.
Jon A. Cruz wrote:
I remember testing both stock items *and* named icons, and seeing positive results for both.
I did not try any of the new "application theme" idea.
By "application theming" I mean looking up the icons we currently pull from icons.svg in the icon theme using e.g. gtk_image_new_from_icon_name() or gtk_icon_theme_load_icon(). The three named icons that are present in the "legacy icons" mapping work, but others don't. This is true at least for the icons that use SPIcon. There may also be some that don't use SPIcon but their own custom mechanism.
Regards, Krzysztof Kosiński
On Feb 11, 2009, at 4:15 PM, Krzysztof Kosiński wrote:
BTW, The "blurry icon issue" is caused by toolbars using 18x18 icons, which aren't standard, and the icons in icons.svg being designed for viewing at 16x16.
Oh, they're not fixed at 18x18. Your computer is just telling inkscape to use that.
Actually, the sizes are queried from the current theme. The current theme says what is standard. Again, one of the main problems here is that different themes and different distros set different sizes as "standard", so one pixmap does not match all.
I actually was finally able to see more of these problems once I started dual-booting into Ubuntu here. I finally saw some of the things that had been annoying Bulia for quite some time, but never quite got described enough to pinpoint.
On Mon, 2009-02-09 at 20:08 -0800, Krzysztof Kosiński wrote:
OK, I have started to work on Inkscape themability. The first task will be to separate the icons from icons.svg into separate files. I put the first portion of icons in share/icons/hicolor/scalable.
Does anyone know whether Gdk-Pixbuf on Windows supports SVG? If it did, it would make everything easier, but if it doesn't, it just means I'll need to create some PNG renders.
You might be interested in these two videos http://blip.tv/file/1075329 http://blip.tv/file/1077148
Here the guy uses a Ruby script to automate rendering of all the PNGs out of a larger SVG canvas.
We're doing something very similar (but in Python) for our icon rendering on the Lumiera project. This script is called as part of our build process. You can see my script here: http://www.lumiera.org/gitweb?p=LUMIERA;a=blob;f=admin/render-icon.py;h=0f9c...
Joel Holdsworth wrote:
You might be interested in these two videos http://blip.tv/file/1075329 http://blip.tv/file/1077148
Here the guy uses a Ruby script to automate rendering of all the PNGs out of a larger SVG canvas.
That's a different animal altogether. If GdkPixbuf supports SVG on Windows, we don't need PNG renders at all, because we can use our SVG icons directly in the theming mechanism. If it doesn't, we have to ship PNG renders. Integrating the rendering into the build process is rather easy, and I have even wrote a custom build system in Perl that renders an icon theme to PNGs of several sizes, but it would be problematic for Windows users. For now I think putting the PNG icons in SVN is the best option, because SVG support in GdkPixbuf is not a part of core GTK, so the logical guess is that it's not supported by default.
Another minor note is that Ruby isn't the best language for build automation, because it's not installed by default in most Linux distros, whereas Perl and Python are.
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
Joel Holdsworth wrote:
You might be interested in these two videos http://blip.tv/file/1075329 http://blip.tv/file/1077148
Here the guy uses a Ruby script to automate rendering of all the PNGs out of a larger SVG canvas.
That's a different animal altogether. If GdkPixbuf supports SVG on Windows, we don't need PNG renders at all, because we can use our SVG icons directly in the theming mechanism. If it doesn't, we have to ship PNG renders. Integrating the rendering into the build process is rather easy, and I have even wrote a custom build system in Perl that renders an icon theme to PNGs of several sizes, but it would be problematic for Windows users. For now I think putting the PNG icons in SVN is the best option, because SVG support in GdkPixbuf is not a part of core GTK, so the logical guess is that it's not supported by default.
Another minor note is that Ruby isn't the best language for build automation, because it's not installed by default in most Linux distros, whereas Perl and Python are.
Wow, this brings back memories of many different threads in the mailing list archives. As a reminder some of the issues were:
1) Dogfood. People wanted to use our renderer for the icons as a visual test and because other renderers weren't up to par. Perhaps a visual test isn't necessary now that we have a visual testing framework that is run regularly. Perhaps other svg renderers have equaled ours?
2) Startup time. IIRC startup times were shown to be significantly faster loading icons from a single file.
3) Convenience for icon designers. Being able to look over a whole theme and judge consistency and share gradients and such was a huge benefit. So I'm sure people would be happy if there was a workflow for generating the individuals from the composite.
I'm sure more discussion points could be turned up if you look through the archives. And yes, it is very likely that many have become irrelevant. Just so that your mindful that this isn't the first or second time someone has attempted to split out the icons and met with resistance.
Aaron Spike
On Feb 10, 2009, at 6:15 AM, Aaron Spike wrote:
- Convenience for icon designers. Being able to look over a whole
theme and judge consistency and share gradients and such was a huge benefit. So I'm sure people would be happy if there was a workflow for generating the individuals from the composite.
Actually, this is an important factor. Once the named icon rendering is completed (the initial steps are what caused our icons to go blurry... the theme engine is asking for one size yet using a different one), I was planning on some enhancements to our icon rendering including supporting jimmac's icon workflow.
We'd been waiting for SVG 1.2 to get published with <multiImage>, but that doesn't look to be happening.
On Tue, 2009-02-10 at 07:59 -0800, Jon A. Cruz wrote:
Actually, this is an important factor. Once the named icon rendering is completed (the initial steps are what caused our icons to go blurry... the theme engine is asking for one size yet using a different one), I was planning on some enhancements to our icon rendering including supporting jimmac's icon workflow.
We'd been waiting for SVG 1.2 to get published with <multiImage>, but that doesn't look to be happening.
The only sane way I could find to solve this for lumiera was to have SVGs that look like this:
http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=icons/svg/tool-arrow....
What you can't see is an invisible layer of rectangles that are used bounding boxes for the rendering script.
Joel
Joel Holdsworth wrote:
On Tue, 2009-02-10 at 07:59 -0800, Jon A. Cruz wrote:
Actually, this is an important factor. Once the named icon rendering is completed (the initial steps are what caused our icons to go blurry... the theme engine is asking for one size yet using a different one), I was planning on some enhancements to our icon rendering including supporting jimmac's icon workflow.
We'd been waiting for SVG 1.2 to get published with <multiImage>, but that doesn't look to be happening.
The only sane way I could find to solve this for lumiera was to have SVGs that look like this:
http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=icons/svg/tool-arrow....
What you can't see is an invisible layer of rectangles that are used bounding boxes for the rendering script.
We also have this implemented in "Breathe". An icon set being developed by the Ubuntu art community.
Ted G. has said it's also possible no to render multiple icons from 1 file. ie: Multiple icons use a folder. So that can be uses as well as other pieces as long as your layers are sorted correctly.
https://launchpad.net/breathe-icon-set
-Cory K.
Joel Holdsworth wrote:
On Tue, 2009-02-10 at 07:59 -0800, Jon A. Cruz wrote:
Actually, this is an important factor. Once the named icon rendering is completed (the initial steps are what caused our icons to go blurry... the theme engine is asking for one size yet using a different one), I was planning on some enhancements to our icon rendering including supporting jimmac's icon workflow.
We'd been waiting for SVG 1.2 to get published with <multiImage>, but that doesn't look to be happening.
The only sane way I could find to solve this for lumiera was to have SVGs that look like this:
http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=icons/svg/tool-arrow....
What you can't see is an invisible layer of rectangles that are used bounding boxes for the rendering script.
Joel
And here is a bit more complex use of that, that we used for gpm (several names, sizes, subfolders): http://bugzilla.gnome.org/show_bug.cgi?id=545886#c6 - Andreas
participants (14)
-
Aaron Spike -
Andreas Nilsson -
bulia byak -
Cory K. -
Guillermo Espertino -
Joel Holdsworth -
john cliff -
Jon A. Cruz -
Josh Andler -
Kalman KHIRALY -
Krzysztof Kosiński -
Michael Grosberg -
Tobias Jakobs -
Yann Papouin