W dniu 24 lipca 2010 22:31 użytkownik Jon Cruz <jon@...18...> napisał:
No, you seem to have forgotten. We discussed this on the mailing list April before last, and you said you would do the PNG versions in response to the note that some icons were coming up blank for different users.
The reason that some icons were coming up blank was that the librsvg loader was not present in Windows devlibs.
No, this is not true. That is a source of many problems. In the past we've definitely seen core Inkscape users have librsvg not handle certain icons and result in mis-rendered or completely blank results. Just because you had seen no problems does not mean *others* are not seeing such problems.
What "certain icons"? If you mean icons created by users for other applications / icon themes, this is irrelevant. If you mean Inkscape icons, see above. When I made the big mess I tweaked all the discrete icons to display correctly with librsvg. In a few cases they contained incorrect SVG that happened to render correctly in Inkscape.
Additionally you have to keep in mind that not everyone runs a GNOME desktop or GNOME applications. KDE is actually quite a popular desktop and application framework, and KDE has *two* main SVG renderers, neither of which are librsvg.
Our application is GTK based so we will not be using KDE's loader. The only icon displayed by KDE's loader when running on KDE would be Inkscape's application icon.
Then we also have mentioned quite a few times that Inkscape intends to *innovate* SVG use, not follow lagging SVG adoption. Among other things we are in the process of implementing multi-res image/icon support. (...)
Application icons are not the best place for introducing experimental SVG features.
So the bottom line there is that we should keep in mind that Inkscape is *not* like other applications. It *is* a high-quality SVG renderer, and we should not slave ourselves to the limitations of just one of the main Linux desktop environments out there. We should help Inkscape promote SVG and lead the pack, not follow the least common denominator of the more restricted use cases.
The fact that the application we're working on happens to include a rich featured SVG renderer designed for interactive editing and high resolution rendering does not mean we can't use a different, more limited renderer for a task that is fundamentally different: quick static rendering of simple vector images at low resolutions. There is no compelling advantage to using Inkscape's renderer to render the icons. Do not give in to NIH syndrome.
No, that is not correct, and has not been for some time. There are some subtle mechanisms in play with our code, including the fact that Inkscape now has successfully been integrated as one of those icon theme sources.
It hasn't. When I call gtk_image_new_from_icon_name, it returns a missing icon image for icons that are only found in icons.svg. sp_icon_new still returns the broken SPIcon widget when rendering from icons.svg, and a GtkImage when fetching from the icon theme, which is a major WTF in itself.
Static system caching of gtk_icon_theme_append_search_path() is just one of those factors.
I have no idea what you're talking about. The effect of this call does not persist when the application is closed.
Regards, Krzysztof