Adding icon cache to kdelibs?

[Aaron J. Seigo]

On Thursday 21 June 2007, Oswald Buddenhagen wrote:
> On Tue, Jun 19, 2007 at 07:30:08PM +0300, Rivo Laks wrote:
> > There will also be some buildsystem changes (I think these should go
> > into 4.0 even if the cache itself won't). Whenever new icons are
> > installed, the icon theme dir's (e.g. share/icons/oxygen/) mtime has
> > to be updated, then the icon cache will pick up the changes.
>
> that's way too error prone. you don't really expect a random gnome theme
> developer to coply with this, do you?

i think this might be less academic if/once we share settings for icon themes. 
until then i'm not really sure it matters one whit.

> distributions would have to run 
> post-install scripts when installing themes.

`touch $foo` isn't rocket science.

> a proper solution is "somewhat" harder and one of the primary reasons
> why all previous attempts at this feature died already in the discussion
> phase:

i seem to recall other reasons as well, but i suppose that's not important ...

> i think the way to go is always deliver icons from the cache as if it
> was up to date on startup. that means whatever is in the cache or a
> question mark if there is nothing.

why not just check what's on disk there is nothing in the cache; e.g. do 
exactly what would normally happen on a failed icon check now. this would 
catch new icons and provide the performance boost for the overwhelming 
majority of icons (how many ?s do you see in your stable apps?)

> then start a backgraound job that 
> does a *proper* scan of the icon dirs. if the icons change, the cache is

how often do icons change? almost never. they change primarily when a new app 
is installed or the theme is changed. on theme change the cache can be 
invalidated and rebuilt (incrementally, as you noted, with use); on app 
installation we're fine if we allow for a fall-through.

> rebuilt (incrementally, of course - it has to stay responsive). for this
> to have any effect, KIcon needs a signal updated() and applications need
> to act upon it (i guess this can be mostly centralized).
> still think you get ready for 4.0? ;)

why bother? just load the icon from disk, when loaded that first time put it 
in the cache, the next time (probably where "next" is defined as "after the 
write lock is released") it is accessed it can be read from the cache. on 
cache invalidation the process naturally starts over, and we already have a 
way to notify apps of icon theme changes.

yes, we could get mired in the whole corner case discussion, but if we look 
around at the real world we'll probably find that the corner cases are truly 
academic here. icons change on disk infrequently and it's almost _always_ new 
icons not replacements of existing ones.

in those odd cases where it is replacements of existing ones, making a rule of 
touching the icon theme root doesn't seem like such a big deal compared with 
the savings we could end up with for the other 99.99% of the time.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070621/b45a94fa/attachment.sig>