March 25, 2009

edelib-new-icon-theme merged

Title speaks for itself :)

Why we needed a new icon loader? Well, because we needed it :P. IconTheme class was way too much monolithic; there you had icon snarfer from the theme, some kind of caching facility to reduce access() and everything that packed in a singleton class. Not bad for some basic usage.

I wanted some things beyond that, mainly to allow dynamic icons reload when the icon theme was changed during desktop session. You know, telling " Please restart your desktop" just because you changed icon theme reminds me on Win 95 days. Don't get me wrong; I'm not fond of the GNOME's instant-apply-on-the-click approach either, but let we leave " Please restart..." way for some serious stuff :)

Also, one thing itched me a lot: checks after icon was fetched. We had before:

String path = IconTheme::get("foo-icon", ...);

if(path.empty()) {
/* try to get "empty" icon */
path = IconTheme::get("empty", ...);
/* bail */

Fl_Image* img = Fl_Shared_Image::get(path.c_str());
/* bail */

/* finally load it */

I already lost inspiration to load some icons.

Now, by introducing IconLoader, things are reduced to this:
IconLoader::set(widget, "foo-icon", ...);
Much better.

This introduces a lot of benefits; first it reduces the code, then it will automatically update widget's image when icon theme was changed (for this Window class must be used) and, most important, allow me to explore efficient ways of icon loading (or whatever) without going in each program and update the changes.

Of course, this solution is not perfect. There is no way to track when widget or image was destroyed (except beeing inside FLTK), so, from time to time, it is good to call IconLoader::repoll() to update internal tracker. This thing is only needed when the large number of widgets or icons are loaded or destroyed in the short period.

IconTheme is still there; now is class related to the only one thing: loading icon theme and it's metadata. This allows loading two different themes in the same time (for example, to fetch descriptions, sample icons and etc.).

Someone will notice similarities with KIconTheme and KIconLoader from kdelibs. That is because I had pretty blur idea how it should be done, so I peeked a little bit how expirienced guys did it. Except similar class and method names, everything else is different.

edelib-new-icon-theme branch also introduced some improvements in Window and MimeType classes (like using user defined icons for mime types).

By the way, recently someone send me a link on discussion from Wolvix forum. Thank you!
Tags: EDE