I scrapped the throw-away version of the KDE <=> Gnome theme converter script which I started many months ago, and started over. I'm trying to do it "right" this time.
It looks like the same index.theme files (if properly written) can be read by Gnome and KDE both, which is nice. I found this handy index.theme specification which should help. Assuming Gnome and KDE implement the spec correctly.
One thing I tend to struggle with is the "big picture". I'm good at getting the details right (or if not right, at least working), but organizing all the bits into a comprehensive, clean whole is something I have trouble getting my head wrapped around at times. Ruby is a nice Object Oriented (tm) language, and that helps a bit with organizing code, assuming a problem maps nicely onto OO-space. But it's oh so very easy to write bad OO code too. Dumping sucky code into a bunch of classes doesn't make the sucky code suck any less.
I think this program is a good exercise in properly abstracting a problem. At the top level is the Theme, which contains Contexts ("applications", "filesystem", etc.), which contain Icons. Probably I need a Size abstraction in there too, each of which contains many Contexts, because each Context can be listed under multiple sizes.
So the end target in all this is really just a bunch of filenames. Now, where should those be put in this abstraction? Do I let the Icons manage and deal with their own absolute pathnames? Or the Contexts? Or the Theme? Or a higher level? Taking a step back, it seems that a relative base directory, "ThemeName", is intrinsic to a Theme, but an absolute pathname, "/home/user/some/dir/ThemeName" isn't; rather the absolute name is part of an operation you do on a theme: "export yourself into this directory". Likewise a Context has (is) a directory name ("applications") and possibly shouldn't care which Theme it's a part of, and an Icon has a filename ("icon.png") and seemingly shouldn't care which Context it lives in.
But the more I think about it, should an Icon know more? Should an Icon know exactly what absolute path on the filesystem it maps to? If not, there needs to be some mechanism to convert Icons into absolute pathnames, somewhere along the line. Where should that go? Should I just crawl down the tree top to bottom, Theme -> Sizes -> Contexts -> Icons, and have it return the pathname that way by building it out of parts? Seems cleaner conceptually, but it's so darned expedient to give the absolute pathname to every object. I think I tend to err on the side of expediency, usually to ill effect, so I'm going to try the other, "proper" way this time and we'll see how it goes.
I also need the ability to sort and search Icons by size; that seems trivial if I have a Size abstraction. And I need the ability to search for Icons by name; seems like a good place to use hash lookups. But I see other possible choices that could work too. Then I just write a tool that takes two Theme abstractions, matches the abstractions in some way, and maps the conversion to real file operations. And some tools to read index.theme files and build Themes from them, and some tools to take a Theme and write out an index.theme file. Seems easily doable. All of these little design questions are the kind of thing that I tend to get hung up (i.e. tripped up) on. It's good exercise at least. I learn a little every time I go through this kind of thing.