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.