On Jul 21, 2010, at 2:34 PM, Joshua A. Andler wrote:
I think it simply boils down to the question of "Is rendering icons when Inkscape starts worth frustrating our users?". My answer is no, because as a user it irks me to no end to wait so long for inkscape to show up. Note, it also really irks me that it presents UI when it's still pegging my processor.
Oh, yes. There are many ways to speed up the icons. However, shipping with pre-rendered ones is not really the solution. With the last attempt we ended up with literally hundreds and hundreds of icons, yet did not even cover the sizes I needed from just running the default Ubuntu theme.
I'd pointed this out a few times, and tried to get help in the past. Basically all we need to do is leverage existing approaches and standards to get the good combination of flexibility, smaller distribution sizes, easier theming and faster startups. One of the standard directories covered by the XDG Base Directory Specification is a 'cache' directory
$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used
Given that usability is a main consideration, adding perhaps 10 seconds to the very first time you run a newly installed program sounds like a very reasonable trade-off. We just need to store the details used to generate the current set of icons so that we can regenerate them as needed. Each time the user switches themes, changes displays, or other such pertinent events occur, we can flag it as invalid and recalc. We can even leave the last few in place to avoid regenerating too often.
BTW, this can be especially important for upcoming GNOME themes and stuff with GTK 3, etc.
It's all very simple. We just need to be sure the proper testing is done to make sure people don't accidentally break themeability as has happened in the past. (I'd prefer to spend my time writing new code, not repeatedly unbreaking existing code)