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.