Re: [Inkscape-devel] Icon sizes
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.