On May 17, 2009, at 10:22 PM, JiHO wrote:

So there is a common pattern (hence a common fix?). Overall, it seems that stock icons (i.e not Inkscape provided ones) scale, but Inkscape icons do not scale. I understand this since Inkscape icons used to be designed and rendered in a different way. However:

• I thought that recent changes to the icon handling would make

Inkscape icons behave as the rest (this was tested with rev 21339 and I haven't seen any icon related changes in the svn log since, and with no custom configuration in .config/Inkscape)

• even if they do not behave as the rest, they should at least display

at their maximum size when the GTK size it set higher that it (32 and 48).

Thanks in advance for any information on all this.

Yes...

This is quite an interesting area. Krzysztof had made some changes without realizing all the implications of behavior for the different cases.

Some needed code has been restored, but the scaling behavior probably won't reappear until the hicolor contents are removed from the build. For testing, you can just find the hicolor directory that contains all the external icons and rename it to something else.

Not following sizing from the GTK+ theme settings is one key thing that the external icons are blocking.

The good news, however, is that the changes Krzysztof did included one that cleared the last bugs complicating external themes. So now all those files that are under "hicolor" can be dropped in to user directories or system ones as an external theme. So now these can be delivered independent of the official Inkscape release install.

On May 18, 2009, at 1:49 PM, JiHO wrote:

Indeed that solves the scaling issue (well sort of, since rendering the vectors at a size they were not intended for makes them look funny, but that's a whole other debate).

Yes, but actually the "Inkscape renders them" solution has a way to address that.

The goal is to support some multi-image and/or level-of-detail changes for target sizes. This can include those proposed for SVG 1.2 (I've been told by W3C members that it will be going in) and also the multi-version workflow that jimmac has worked out.

We actually would have had that going by now, but instead of being able to support that I have had my time taken away fixing things that were ripped out improperly.

I guess by "external icons" you mean getting them from a directory with bitmap icons at different sizes, as all other GTK apps do.

Yes. Mainly. But remember that "all other GTK apps" do not have improved SVG rendering in them. Most only have the subset that librsvg has chosen to implement.

So, if I understand correctly, removing the hicolor dir (hence the external icons) falls back on rendering them on the fly from the SVG source (as was done before). This currently has several "drawbacks":

Do you think you can add a simple chart to the icon page on the wiki? This is really the sort of thing that is easier to sort out there.

http://wiki.inkscape.org/wiki/index.php/Icons

***HOWEVER*** the number one point to address with these icon issues is to list them out separately. There are many separate issues that overlap, and not looking at them as separate is the main thing confusing solutions. The times I've been able to find Krzysztof in our chat room it has become clear that this is probably the number one cause of the mistakes he is making.

• it uses the old icon theme, not the new tango-like one on which many

people worked to make it better. I don't want to start another flamewar between tango/old theme, but I am just saying that switching from one icon rendering method to the other should not change the theme.

Yes. Those are completely separate things. I was trying to fix that, but then had the icon code changed out from underneath me. The simple solution, though, is only about a single evening's work to implement... as long as the icon code stops being changed from underneath me.

• it adds a lag to startup: 6-7 seconds with external icons, 11-12

without. And this is increased when the rest of the machine is busy already.

You need to list out the details of what system you are seeing that on. Some people have observed no difference, and some have observed broken icons. One rule of performance tuning is that it does not matter how fast you do something, if it's not actually doing the right thing. :-)

I understand that icons have to be rendered from the SVG but was there not some kind of caching that Mental introduced? Doesn't it persist between startups?

The caching mental put in was per-run and in-memory only. I later added changes that made the startup render things in the background. That sped startup significantly.

Additionally, our work to use the standard XDG directories includes support for their "cache" directory. Hmmm... a standard local directory for apps to "cache" things under???? :-)

So for both compatibility purposes (with the regular theming mechanism of GTK apps)

BINGO!!!!

This is JiHO icon issue number 3, not issue number 1 again. (Remember how I said we had separate things overlapping?)

The internal rendering (from a single icons.svg file) is 100% compatible with regular theming mechanisms of GTK apps. The bottom line here is that any individual who "themes" other apps can take their exact same steps and theme Inkscape... completely independent of how Inkscape is getting its initial default icons.

The reason you see different styles is that Krzysztof did not listen to me, and failed to change to loading "tango_icons.svg" when he changed the other ones to the tango look.

and from a performance point of view, external icons seem better. The drawback is that they put more strain on the icon designers. But there is some kind of script that should allow to export all icons at all sizes from a common document by leveraging the export all groups feature of Inkscape.

This is another place where things start to really break down with external icons (and again, good to toss in a table on the wiki). Hmmm... for the wiki perhaps you can do a table with each feature/ issue down the left side, and "internal", "external" and "notes" across the top.

Anyway, there was a script added that was intended to do that. The first problem is that the script is broken, and won't run for many people including myself. This has been pointed out to the person who put in the script, but it has not been fixed.

The bigger problem is that the concept itself is wrong. The fixed- sized PNG versions were added as a work-around for systems that did not have librsvg to the latest version. Also.. the source SVG icons themselves were also dumbed down to work for librsvg, and thus lost some Inkscape features. However, only two sizes were done for each icon. So if you happen to be running a theme on a distro that just happens to match those sizes, then you are ok. However... right off the bat our app uses *THREE* gtk sizes, not just two. (however, it happens that Ubuntu sets their default theme to have two of those sizes set to the same value). Additionally, many platforms don't use those exact values, so you get blurry pixmap scaling, missing icons, etc.

This also breaks down for those with hi-res displays. Currently I switch between laptops with significantly different DPI (1440x900 compared to 1920x1200 on the same 15.4"), so on one 16x16 might be quite sufficient, but on the other the icons come in too small to be of any real use.

It also breaks for any themes tweaked for accessibility such as "Large Print" and similar.

So then, what is needed to have the external icons work properly? "Just" design some at bigger sizes (32 and 48) and export them together with the currently existing sizes (24, 16) in hicolor? If the tango icons look good as they are, then I guess the people that worked on them could scale and touch them up a bit at these large sizes to complete the icon set.

No. Basically we can't get fixed bitmaps that will work without adding in thousands of extra images (literally).

[Note: I am perfectly happy with 24 and 16 because we ship with a custom theme on OS X and I can set the sizes there (and I have a small screen so 24 and 16 are nice). But I guess people with external GTK themes and/or big screens might what bigger ones]

DOH!!! you're broken. Icons are supposed to be 22x22, not 24x24. :-)

Not just bigger screens. Higher DPI screens too. Apple ships products ranging from 94 DPI up through 134 DPI (that's a 43% increase there). And Dell has that one that is 147 DPI, so it's not a rare thing.

On May 23, 2009, at 7:13 PM, Krzysztof Kosiński wrote:

Jon A. Cruz wrote:

...

The internal rendering (from a single icons.svg file) is 100% compatible with regular theming mechanisms of GTK apps.

It is not compatible with many convenient GTK APIs, for instance Gtk::Action::create_with_icon_name.

Yes, it *IS* compatible with all of those GTK APIs.

I have seen it working with my own eyes

Did you even bother to test any of your assertions, or are you just making blind guesses???

There is no way to convince Gtk::IconTheme to fetch named icons from the monolithic file. One can define stock icons for every icon used in the application or add builtin icons to the icon theme, but those approaches don't work with scalable icons.

Please review the code that is in play when icons.svg *is* used. It does use the theme mechanism. Your assertion that there is *no* way to do this is not true.

...

The bigger problem is that the concept itself is wrong. The fixed- sized PNG versions were added as a work-around for systems that did not have librsvg to the latest version.

They are a workaround for systems that don't have librsvg at all, and I don't like it. The real solution is to either bundle librsvg on those systems, or write another GdkPixbuf loader for SVG that will use our renderer. Those are the only ways to be able to use all the convenient APIs for named icons. I would opt for the former because it is much less work and has superior performance (librsvg is quite fast, in my tests it was even slightly faster than loading PNG icons).

No... those are *not* the only ways to do that.

Again, the current icons.svg file code *does* work with icons, falling back, etc.

Here too is another key point I need to stress. You keep ignoring this. Please listen this time

WE CAN NOT USE LIBRSVG TO GET FULL FEATURES OF SVG!!!!

That is *BY DESIGN* of librsvg. They have improved many things recently, but they are intentionally *not* targeting full SVG support.

...

Also.. the source SVG icons themselves were also dumbed down to work for librsvg, and thus lost some Inkscape features.

When I extracted icons from icons.svg, I had to modify exactly one icon (randomize.svg). And in fact it was just fixing malformed markup that was interpreted by Inkscape as correct. By the way, all other SVG icons in existence are also "dumbed down" for librsvg, yet there are some beautiful icon sets out there, so the limitations can't be that severe.

No...

Here is another key point.

They did not break for *you* but they *DID* break for other people.

Please keep in mind that not everyone will be running the latest and greatest versions of all libraries. You *must* keep cross-platform support in mind for any code work you do on Inkscape. One of our key promises is good cross-platform support.

On May 25, 2009, at 5:25 PM, Krzysztof Kosiński wrote:

OK, I wasn't correct. There is no obvious and easy way in the GTK documentation to do this. One can use gtk_icon_theme_add_builtin_icon, but it can't be used to add scalable builtin icons, we'd have to re- render them in response to logical icon size changes. If we had a list of icons and logical sizes at which they are used, this could work.

Guess what?!?!?!?

THAT IS EXACTLY WHAT WE DO!!!!

That is, the code that you declared dead and useless does just such work. So your removal combined with these statements seems to be a clear indication that you did not fully grasp all that was going on in that source file.

...

Again, the current icons.svg file code *does* work with icons, falling back, etc.

It does work but:

1. It seems I have to use sp_icon_new instead of

gtk_image_new_from_icon_name. Thus GtkImageMenuItem, GtkAction, etc. won't work correctly unless they are subclassed.

That is true...

However if you read through our source code you'll see that things *are* properly subclassed. Also that is much of the reason for using a factory design pattern. It makes things easy. (Please read up on at least the most common design patterns).

2. At present the fallback order is a bit off. (icons.svg from user

folder should be first, themed icons second, and system icons.svg last; currently it is themed icons, user icons.svg, system icons.svg, unless there were some changes I didn't notice)

Yes, the order does need a bit of tuning. If you look to some of the XDG discussions you'll see that it was something I was asking for assistance with before the other distractions and code changes came up. I believe I also stressed that XDG compatibility with you explicitly.

...

WE CAN NOT USE LIBRSVG TO GET FULL FEATURES OF SVG!!!!

Yes, but I think that full features of SVG are not necessary for icons. Everyone else is confined to the librsvg subset and they create excellent artwork. It should not be a major problem for us to stick to it. Another thought: if Inkscape's icons are not librsvg-compliant, they are less useful, because people can't reuse them or their modified versions in desktop themes. So using librsvg, even it's not as technically appealing as reusing our canvas renderer, has a few real advantages (speed, memory footprint, icon compatibility with desktop themes, convenient APIs).

Well... that is your opinion. The opinion of many others is the opposite. Also keep in mind that you have only really been testing with the latest versions of librsvg; older versions have more problems but still are in use.

Speed is a non-factor with caching. Memory is a minimal factor due to many things. Icon compatibility is easily achieved with other means that do not dumb things down 100%. Convenient API's is really a red herring, and not a pertinent factor here.

Again, on this point you are effectively telling all the artists that they *MUST* work with a constrained, distro-specific set of restrictions. Adoption of such restrictions really should be up to the individual using artist to decide on a job-by-job basis.

An exception to this is filter icons: of course they can't be rendered by librsvg, and there is no reason for them to be themable because they are just illustrations of the filters' functions, so they should still be rendered by Inkscape.

Here is a point of software engineering. It is usually better to have a simple codepath that supports the needed functionality instead of special-casing various one-off cases, especially if there get to be more of those. Keep It Simple Stupid, or KISS, is how that is often referred to.

...

Please keep in mind that not everyone will be running the latest and greatest versions of all libraries. You *must* keep cross-platform support in mind for any code work you do on Inkscape. One of our key promises is good cross-platform support.

I agree, the icons need testing on more versions of librsvg

Finally I'll point out one additional feature proposal that you seem to have missed out on catching. The icon workflow, including the icon preview, is being tweaked to include previews rendered by engines such as librsvg. We don't want to compile this in where we can avoid it (since it does avoid an extra dependency on another external library). But the good news is that we can do this in such a way as to support more than just GNOME.

Remember that KDE has it's own very nice SVG rendering. Recent versions of KDE have really jumped ahead in SVG use. So given that the icon workflow is being tweaked to use librsvg through an external hook where possible will simultaneously open it up to support KDE's SVG rendering. Personally I'll be using it with three previews side- by-side: Inkscape internal, librsvg (for GNOME) and KDE.

Oh, and in case you didn't know, many of the KDE artists use Inkscape to do their work in.