On Tue, 4 Jan 2005, bulia byak wrote:
- rsvg is broken. Talk people who are drawing icons in Inkscape to be
rendered by rsvg (e.g. Brisgeek). There are lots of complaints. I don't want this problem for us.
Agreed. FWIW, this is the main issue that matters to me.
- Don't Fix What Is Not Broken (TM). I see no real problems with the
current implementation.
It is fairly ugly, code-wise...
If it was possible to use it with GTK, I'm sure it's possible to use it with gtkmm as well.
Yes, we could do a cleaner version of the same general approach, or even pre-populate an IconFactory with pre-rendered icons.
amounts of small icons and simple graphics for GNOME. It may not be as high quality or compliant, but it's not supposed to be a super leet drawing app, and it's likely much faster than Inkscape's renderer at putting the icons into a pixbuf.)
Even with our current slow-as-hell renderer, rendering icons are in no way a speed bottleneck.
IIRC from my last bit of profiling work, there is a visible performance impact when creating new windows, but you are correct that it's not been an issue during use otherwise.
Have a look at how simply icons are done in the Gtkmm code: http://cvs.sourceforge.net/viewcvs.py/inkscape/experimental/bryce/inkscape_g...
Currently it's just as easy, except that you use ids not filenames.
IMO, we really shouldn't be using filenames directly. But I would prefer GTK stock IDs (mapped to icons.svg ids on the backend) rather than using icons.svg ids directly, if possible.
In my ideal little world, IconFactory would be subclassable or something so that we could make an IconFactory that used our renderer to render icons on-demand. Sadly, I don't think that's possible yet.
In lieu of that, I'd prefer a pre-populated IconFactory filled with pixmaps using our renderer. From there on up we can use the standard GTK icon facilities directly.
-mental