kiconloader

had a slightly rougher than usual week in the personal life segment. additionally school is out for winter break until this coming monday, so i also have the p-man around full time. it's certainly nice: we get to cook together, put lego together, watch movies until 2 in the morning, etc.. but all told this week's personal load is putting pressure on my ability to concentrate and work uninterrupted.

this didn't stop yesterday's lib tuesday from rocking pretty hard though. there were several people who showed up with their own bits to add. olivier goffart did a ton of work, for instance, on further de-guifying libkdecore. we've been discussing on kde-core-devel what to do with the last few bits that remain; it looks like kconfig is going to be the biggest remaining blocker, which means i have a really, really good reason to finish up the work i started last year on kconfig since it resolves most of the issues already while finishing out some of the design goals of kconfig, such as pluggable back ends.

one of the major changes that happened due to my hands yesterday was moving KIconLoader out of KInstance. previously, if you created a KInstance you got an icon loader too. but the icon stuff relies on various bits of gui stuff (no surprise there, really) and so got moved into kdeui/icons. what now for apps that need an iconloader?

well, instead of doing either of these things:

KGlobal::instance()->iconLoader();
KGlobal::iconLoader();

one would now do

kapp->iconLoader();

this looks like more of a change than it really is. in the previous case you needed a KInstance. calling the static method in KGlobal had the same requirement. so now KApplication becomes "the KInstance for GUIs".

i did consider making KIconLoader a singleton, but it would still rely on having an existing KInstance around and that just seems to be better communicated by having one access it via a KInstance (in this case, KApplication). moreover, it's not uncommon to have more than one icon loader around in the case of multiple components (e.g. kparts or plugins) that have their own icon search paths. so having a singleton pattern could be a bit misleading.

but there is a remaining challenge to this: what do kparts, ioslaves and plugins do now? in the past they'd create their own KInstance and then do something like:

instance()->iconLoader();

now they need to create their own icon loader, such as:

m_iconLoader = new KIconLoader(instance()->instanceName(), instance()->dirs();

this has become a fairly common idiom while porting the kde4 code base over. which led me to think about creating a KParts::Instance class which restores the old behaviour for these cases: a KInstance with a bundled KIconLoader, much like KApplication does.

seeing as it will be pretty much exactly the same code as in KApplication, i'm further considering creating a small interface class with those few methods needed to Do The Right Thing(tm) and have KApplication, KParts::Kinstance, etc inherit that interface. this would allow me to centralize the code in one place and ensure the naming is consistent. this means KApplication would MI from QApplication, KInstance and this new icon loader access interface thing. not sure how i feel about that exactly =)