Le 13 févr. 05, à 16:57, M. Uli Kusterer a écrit :
One thing that may not be obvious about IKIcon is how I envision a
theme switch to happen, so I thought I'd elaborate that here in case
you see any flaws and so it's recorded somewhere when it comes time to
implement this.
ok
Basically, every IKIcon that is a standard icon knows its icon
identifier, and thus knows how to reload its icon image from the
corresponding image file from the current theme. To do this, you use
the -update method.
Every composited icon, OTOH, will eventually carry a pointer to the
two IKIcon objects it is based on around. That way, when the theme is
changed and e.g. the folder icon changes, all IKIcons that are badged
folders can register for the icon updated notification of the icon
they're based on and re-composite themselves with the updated icons.
We should probably implement such solution I think.
So, whenever a theme switch happens, all the icon provider will have
to do is call "update" on the icon cache, and all icons on the display
should upgrade automatically. Of course, anyone who held on to the
NSImage won't get the update, but those using the IKIcon at least
will.
Themes switch (icons included) wasn't currently planned to be instant,
it was planned to be done upon applications launch, but may be such
possibility can be studied with pixmaps themes for Camaelon or
eventually for icons retrieved with NSImage (we could hack NSImage with
such feature).
A possibility for themes supports is to have Camaelon using IKIcon for
pixmaps elements, then it would be easy to have them altered on the fly
with notifications when a theme change happens, and because Camaelon
and IconKit has been really created to be used together, having
Camaelon relying on IconKit isn't a problem, it would avoid the need to
hack NSImage (Anyway fallback on NSImage could be implemented for
Camaelon when IconKit isn't installed…)… Nicolas what do you think ?
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
