On Sun, 2 Jan 2005, Andreas Nilsson wrote:

...

...

I really hope that the developers will not reinvent theming and that the move to gtkmm and the greater use of standard widgets will make it easier to support the existing standards for icons and themes as GTK already includes support for SVG themes.

This is exactly what Bryce and I are trying to do with our work in the Gtkmm codebase.

On Sun, 2005-01-02 at 10:42 -0800, Bryce Harrington wrote:

Can you please do some research and see if you can scare up some officialish documentation on toolbar theming with Gtkmm for us? We're about to a point where we could start implementing it if we had the docs on hand.

I've got it pretty much figured out by now. I had to complete the task of fleshing out all the necessary StockIDs before I could get started, though. We need to use IconFactory/IconSet objects to tie Inkscape- specific icons to Inkscape-specific StockIDs (for an end result similar to Gtk::Stock::* or GTK_STOCK_*).

I need one thing to finish the icon work in the Gtkmm code: Could anybody here write up a script to rip apart icons.svg into separate files?

A single icons.svg file is convenient for artists (a single place to work on all the icons), and its where the legacy code gets all its SVG icons, but it doesn't play well with IconFactory. I need separate .svg files per icon.

Can someone script this up, so we can automate the creation of the separate icon files from icons.svg?

As soon as I get separate icons files, I'll get them implemented in the Gtkmm codebase (and we'll have icon themes as an inherent byproduct of properly implementing StockID/IconFactory).

Thanks,

Derek

(Btw, the Gtkmm code now has theme-able keybindings via '/usr/share/inkscape/ui/keybindings.rc'. The morning of New Year's Eve, I decided to finish all the menu-related StockIDs/StockItems and implement loading keybindings from a file at runtime via AccelMap before the Old Year was up. I completed my goal with 45 minutes to spare, while riding in a car from one New Year's party to another. *grin*)

On Mon, 2005-01-03 at 04:46 -0600, Bob Jamison wrote:

Does the file really need to be broken up?

I think so, yes.

We are already using the IconFactory

Only for the old .xpm icons and not in any standard fashion.

The sp_icon_new_* family of functions have nothing to do with IconFactory, and are used by Sodipodi/Inkscape "propriety" methods of handling things like icons in menu items and toolboxes, etc.

The way it'll be done in the Gtkmm code will be 35,000% more clean and correct.

With the Gtkmm wrapper of IconFactory, it would seem to be easier to do this wedge in Gtkmm with a simple subclassing than is already done in Gtk/C. A little bit of C++ coding by a couple of people could save many hours of work for many others.

I didn't imagine that writing a script to explode icons.svg into its separate files would be that complicated. I mean, Inkscape already does some fashion of this in C using Inkscape's render.

The only problem right now with porting sp_icon_image_from_svg() to the Gtkmm codebase and its use of IconSource/IconSet/IconFactory is that the Gtkmm code doesn't yet have the Inkscape renderer.

All I can do right now in the Gtkmm code is have GTK+ load each icon separately based on filename and have it automagically rendered via librsvg where ever its required according to the StockID it's associated with.

Besides, parsing icons.svg complicates the code quite a bit more than simple repeated calls to IconSource::set_filename().

On Mon, 3 Jan 2005 07:44:01 -0800, Kees Cook <inkscape@...62...> wrote:

...

I didn't imagine that writing a script to explode icons.svg into its separate files would be that complicated. I mean, Inkscape already does some fashion of this in C using Inkscape's render.

It's not simple. Some of the icons depend on eachother (for their elements or gradients, clones, etc), and the offset/size information comes from the rendered bounding box. That was one of the reasons for merging them into a single file; it's easier to maintain a certain look/feel.

I second that. Another reason icons should stay in one file is that breaking them would slow down Inkscape loading a lot. It's a very sensitive area because people strongly dislike programs that take forever just to start up. So please rethink this aspect.

...

All I can do right now in the Gtkmm code is have GTK+ load each icon separately based on filename and have it automagically rendered via librsvg where ever its required according to the StockID it's associated with.

I'm also against using librsvg in any manner or form. Not only is it a new and redundant dependency, but it is known to be broken in several important ways. We must use our own renderer, if only because it's safer (created and displayed by the same app, no surprises) and helps discover Inkscape bugs (it's like running a test suite on each loading of the program).

On Tue, 04 Jan 2005 12:47:07 -0600, Derek P. Moore <derekm@...606...> wrote:

Actually, the way Inkscape handles icons now, it renders every instance of an icon separately. So the same icon in three different places gets rendered three times. With librsvg's gdk-pixbuf loader and IconFactory, the icon is only rendered once and the resulting pixbuf is used everywhere the icon is used.

The overhead from reusing the same icon in different places is negligible. What is not negligible is parsing every SVG file separately. Of course it may be that rsvg renders separate SVGs faster than Inkscape renders its icons.svg, but again, icon rendering is not a bottleneck currently.

As soon as Inkscape's renderer works as seamlessly with GTK+ and is available as a dynamic gdk-pixbuf loader, I'll agree with you.

Is it too hard to make a gdk-pixbuf loader out of it, capable of rendering icons by their ids from a single file?

On Tue, Jan 04, 2005 at 03:04:25PM -0400, bulia byak wrote:

Is it too hard to make a gdk-pixbuf loader out of it, capable of rendering icons by their ids from a single file?

We already have this code. It's what we do right now. See widgets/icons.cpp; there is even a C++ version of it.

On Tue, 2005-01-04 at 15:04 -0400, bulia byak wrote:

Is it too hard to make a gdk-pixbuf loader out of it, capable of rendering icons by their ids from a single file?

Well, gdk-pixbuf loads and renders whole files. There's no mechanism by which to tell it to render only a component of a file. See: http://developer.gnome.org/doc/API/2.0/gdk-pixbuf/

As for making Inkscape's renderer a dynamic gdk-pixbuf loader... I don't imagine it would be too difficult. Personally, I wouldn't know where to start. But, Bulia, you may know enough about Inkscape's renderer to do it.

Basically it would mean turning Inkscape's renderer into a shared library (which might benefit Inkscape along the way). You'd also have to write a 'loader' shared object and an 'engine' shared object for GTK+ to use Inkscape's renderer library (they go into /usr/lib/gtk-2.0/2.4.0/engines/ and /usr/lib/gtk-2.0/2.4.0/loaders/).

If it's possible to be done, it could help Inkscape, GTK+, and GNOME all at once. It could help Inkscape by making the renderer's interface more clean and modular. It could help GTK+/GNOME by providing a higher quality alternative to librsvg, which would become more and more viable as Inkscape's renderer speeds up and becomes more efficient. And it could help the rest of the Free Software world by providing a very high quality SVG rendering library to reuse.

But all that's certainly not something I can undertake. I simply don't know enough about Inkscape's internals.

On Tue, 4 Jan 2005, Derek P. Moore wrote:

As for making Inkscape's renderer a dynamic gdk-pixbuf loader... I don't imagine it would be too difficult. Personally, I wouldn't know where to start. But, Bulia, you may know enough about Inkscape's renderer to do it.

Basically it would mean turning Inkscape's renderer into a shared library (which might benefit Inkscape along the way). You'd also have to write a 'loader' shared object and an 'engine' shared object for GTK+ to use Inkscape's renderer library (they go into /usr/lib/gtk-2.0/2.4.0/engines/ and /usr/lib/gtk-2.0/2.4.0/loaders/).

If it's possible to be done, it could help Inkscape, GTK+, and GNOME all at once. It could help Inkscape by making the renderer's interface more clean and modular. It could help GTK+/GNOME by providing a higher quality alternative to librsvg, which would become more and more viable as Inkscape's renderer speeds up and becomes more efficient. And it could help the rest of the Free Software world by providing a very high quality SVG rendering library to reuse.

An arguably better approach may be to do the above, but base it off of Cairo instead of Inkscape's renderer. Cairo is also being woven in at the X.org level so my guess is that long term it will become the preferred SVG renderer, over librsvg.

We've talked seriously about eventually replacing Inkscape's renderer with Cairo one day, so it would be in keeping with our plans. It has a well defined API, and is broken up into multiple lib's, allowing us to only load in the specific components required.

The downside is that the time for adding Cairo as a dependency for Inkscape still appears to be in the future. More work is required both on Cairo (speed/capability improvements) and on Inkscape (to be able to hook into alternate renderers). So it may be a little premature to consider it for something like icon rendering. However, it could probably be the most efficient and effective use of effort.

Bryce

On Mon, 3 Jan 2005, bulia byak wrote:

I'm also against using librsvg in any manner or form. We must use our own renderer, if only because it............ helps discover Inkscape bugs (it's like running a test suite on each loading of the program).

I've seen this argument utilized several times since the incorporation of the SVG renderer for the icons. Early on, I think the argument made sense, however today I think it is out dated, for the following reasons:

a) Regression tests do not need to be run over and over on the same released codebase. If rendering icons has any value, then it can be achieved via ONE run, plus a thorough inspection. It makes no sense to impose running a test suite on every user every time they run it, when it is guaranteed to always give the exact same result.

b) We now have sufficient organization and infrastructure to put together much better regression tests than would be obtained via rendering of toolbars. (And we ought to do so.)

You yourself made a point in this thread regarding breaking up icons.svg into multiple files, expressing the concern that loading from multiple files would make startup time slower than loading from a single file.

Clearly, if it is a goal to minimize startup time, then this strongly suggests stopping the svg render on initialization. The SVG rendering completely overshadows the performance loss from loading from multiple icon files.

Probably the fastest would be to pre-render all of the icons into a single runtime-encoded bitmap, enabling the entire data set to be loaded into memory in one operation. Games do this all the time with their icons, so the technology is very well understood.

But even if this is not done, at least eliminate the svg rendering during loadup. It's benefit as a regression test is negligible, but its performance impact is quite significant. Instead, use the renderer but cache the results; this gives us the best of all worlds, for the cost of a little coding effort.

Bryce

Kees Cook wrote:

On Mon, Jan 03, 2005 at 05:58:27AM -0600, Derek P. Moore wrote:

...

...

Does the file really need to be broken up?

I think so, yes.

I think you're going to have to make other plans. :(

...

I didn't imagine that writing a script to explode icons.svg into its separate files would be that complicated. I mean, Inkscape already does some fashion of this in C using Inkscape's render.

It's not simple. Some of the icons depend on eachother (for their elements or gradients, clones, etc), and the offset/size information comes from the rendered bounding box. That was one of the reasons for merging them into a single file; it's easier to maintain a certain look/feel.

Speaking of icons, have anyone read this higly intresting proposal over at freedesktop?: http://lists.freedesktop.org/archives/xdg/2004-October/005084.html Just as I would like programs like Scribus blend in better with my Gnome desktop, I belive a Kde user would like Inkscape to blend in with the default theme for his/her desktop of choice (without having to rely on internal theming settings as have been proposed on this list). That would be possible if we used these standardlised icon names. But well, that is when the different desktops starts using this standards.

About the look and feel. If the icons were to be broken up i separate files, would it be possible to do some kind of stylesheet, containing gradients, strokes and colors that the icons could share? Might perhaps also reduce the loading time a bit. - Andreas

? With separate svg files how were you going to render those?

With GTK+'s native support for SVG icons. I'm simply going to pass GTK the filenames and nothing more.

Is that just temporary? I thought we wanted to use Inkscape's renderer. If you're going to do something temporarily, I would recommend writing a quick hack to inkscape to export all the icons from icons.svg into separate png files and just use those until your tree is merged.

Ideally it would be permanent. It's the Right Way To Do It(tm); it makes for the simplest, most straight-forward code; and what difference does it make whether icons are rendered with Inkscape's renderer or librsvg? They're just icons. (Besides, the sole purpose of rsvg is to be a compact and portable renderer to very quickly render massive 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.)

Also, the icon is only rendered once by rsvg's gdk-pixbuf loader when its put into the IconFactory. Whereas, in Inkscape's "proprietary" way of handling icons, the SVG is rendered each time its displayed in a different location (e.g., toolbar icon of 'zoom_select' vs. menu item icon of 'zoom_select').

Have a look at how simply icons are done in the Gtkmm code: http://cvs.sourceforge.net/viewcvs.py/inkscape/experimental/bryce/inkscape_g...

Any icon needed for the GUI goes into 'icons.cpp' and is referenced in the rest of the code via its corresponding StockID (in the Inkscape::UI::Stock namespace).

rsvg works with GTK+ seamlessly via filenames, just as easily as .png's, .jpg's, or .xpm's. This doesn't introduce a librsvg dependency on Inkscape... But it does introduce a "runtime dependency" on GTK+. GTK+ will need to have librsvg's dynamic gdk-pixbuf loader available. Nearly all modern Linux desktops have this available by default, and if its not there, it's terribly easy to install.

I can't say anything for Win32, however. librsvg's gdk-pixbuf loader /ought/ to be available for GTK+ on Win32, but I haven't used Win32 for years and don't have it available for testing on any of my computers.

Every other project in the world uses separate icon files (though almost invariably PNGs). It would make it easier for other projects to steal (i.e., share) Inkscape's icons. And it would make it easier for others to contribute icons to Inkscape. As evidenced by Andreas Nilsson's email to inkscape-devel yesterday, where he submitted 3 SVG icons to replace old XPMs, separate filenames for icons is the natural way of going about things for almost everyone.

Am Dienstag, den 04.01.2005, 12:49 -0600 schrieb Bob Jamison:

Derek P. Moore wrote:

...

I can't say anything for Win32, however. librsvg's gdk-pixbuf loader /ought/ to be available for GTK+ on Win32, but I haven't used Win32 for years and don't have it available for testing on any of my computers.

You noted a very important point. This -must- work on Win32, else it is not an option. Gnome-ishness is relatively unimportant.

That's not a problem. Look at Gimp, they are using librsvg on Windows, too. And btw, I think Gnome-ishness is more importent then Windows-ishness. ;-)

Tobias

Hi guys!

I _do_ see Derek's point here! His approach will make it easier to move away from custom icons in the future and integrate with freedesktop icons specifications, if more easily, once they are out the box. While the rendering works fine as is right now, I can guarantee, that the icons as they are will also be correctly rendered by librsvg. I've myself cursed librsvg for not rendering my icons properly, but it always has been a matter of gradients and transparencies within icons that at some point were created with CorelDraw. Text doesn't work either, but heck, this is nothing to care about for the inkscape icons. I don't think that the approach of handling over the icons to librsvg does definitely involve ripping apart the file. It might as well be possible to first extract them from the file into a temporary svg and hand this one over. Another advantage here would be that the icons will fade in with the rest of the desktop a little better. My theme is making use of icons having lower saturation and opacity in normal state, higher in prelight state and very low ones in insensitive state. Therefore even for markers and such, I'd make sense to have librsvg render them. Right now these preferences are not adapted by Inkscape, which is a pity IMHO.

Take care!

David

Attached is a screenshot of Inkscape next to its younger brother from the Gtkmm codebase. You'll notice the icons do render a bit

differently

when passed through librsvg (they're not as crisp). And the only icon that has a problem with librsvg is fill-stroke.svg, as you can see in the screenshot.

I have to ask... is there control over librsvg's parameters for output? I'm wondering because the lack of crispness/over anti-aliasing is pretty bad. They look almost blurred, which is not good. Before I even read the message I popped open the image and the difference in clarity stood out like a sore thumb. The node editing tool icon looks especially bad in my opinion.

Just my .02... -Josh

On Tue, 4 Jan 2005, Derek P. Moore wrote:

...

While the rendering works fine as is right now, I can guarantee, that the icons as they are will also be correctly rendered by librsvg.

Attached is a screenshot of Inkscape next to its younger brother from the Gtkmm codebase. You'll notice the icons do render a bit differently when passed through librsvg (they're not as crisp).

Very cool, thanks for posting the screenshot.

The rendering differences for librsvg are a bit disappointing, but for now it's great to see them in the codebase. I also did a quick performance comparison to see what impact the svg rendering imposes for startup time. Came to about 10% roughly, which is about what I expected. Inkscape's renderer has a larger impact, but I don't have comparible figures for that.

I still suspect that the best solution for us would be to use the Inkscape renderer but cache the pixmaps. This approach would have the following pros/cons:

+ High performance for startup since loads from cache + Can use the best render available, even if it is slow + Allows for theming; just requires regenerate the pixmaps + Allows us to avoid adding librsvg as a dependency - Involves some new code to manage the cache - Bitmapped toolbar icons aren't considered "cool" ;-)

That said, I think librsvg is a good solution for right now, since inkscape_gtkmm does not have access to Inkscape's renderer currently. Once we merge, and the full renderer is available, though, this would be worth doing imho.

Bryce

On Tue, 2005-01-04 at 15:58 -0500, MenTaLguY wrote:

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.

What could be done is this...

The Inkscape::UI::Icons namespace could have its own version of the sp_icon_image_from_svg() function. It would have to return a Glib::RefPtrGdk::Pixbuf, instead of a pointer to an array of guchars.

I could then do something like: src.set_pixbuf(get_icon_pixbuf("draw_select")); ... instead of ... src.set_filename(get_icon_path("tool-select.svg")); ... as it's done now.

However, this get_icon_pixbuf() function has to wait till the Gtkmm codebase has access to Inkscape's renderer, which it currently doesn't.

Am Dienstag, den 04.01.2005, 14:57 -0400 schrieb bulia byak:

On Tue, 04 Jan 2005 12:33:51 -0600, Derek P. Moore <derekm@...606...> wrote:

...

Ideally it would be permanent. It's the Right Way To Do It(tm);

You haven't convinced me still.

1. 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.

The only problem I have with it is the text support. But I would not call it broken.

2. Drawing icons consistently is much easier when they are in one file.

Jep, thats right.

3. Loading them from one file is faster too.

Some lines below you wrote: "Even with our current slow-as-hell renderer, rendering icons are in no way a speed bottleneck."

4. Don't Fix What Is Not Broken (TM). I see no real problems with the

current implementation. If it was possible to use it with GTK, I'm sure it's possible to use it with gtkmm as well. With the necessary support code, passing an id to get an icon is just as easy as passing a filename.

Don't reinvent the wheel (TM). Why think about something, that is solved in 1000 other apps, just let gtk care about the icons. And doesn't inkscape already use gtk-stock-icons in some places?

Yes, of course it is nice to use our renderer for the icons just because we can do it, but that is not the goal of the program. We even don't render the buttons with our renderer. ;-) With the the standard GTK icon facilities you can use PNGs or SVGs directly, you just don't need to care about it.

Tobias