Well, I do have reservations about this. For one, the original purpose of Pierogi was to create a little experiment of my own; I knew that many CIR control systems were similar to each other, and I wanted to see if I couldn't compress keysets together by creating families of similar controls. And, I went ahead and used the C++ class inheritance scheme to implement these families. As such, there are a lot of concepts built-in to the current Pierogi system that would be difficult to explain to the general public.

Second, Pierogi is way late to the game here. The N900 originally launched with an IR remote control mechanism that uses 100% human-readable keyset files; that is, the Linux Infrared Remote Control (or LIRC) project. (And the Irreco / QtIrreco project built a GUI shell around it.) So, you can today set up the LIRC server on your N900 and run your own config files on it. (Although, I do have to admit that calling LIRC config files "human-readable" is a bit of a stretch; the syntax they use is, honestly, pretty awful.)

However, let me make this counter-proposal: what about a two-tiered keyset mechanism? It shouldn't be hard to let Pierogi continue to support its internal set of keysets (following my rather obscure implementation mechanism), and then optionally read in a set of more standard external config files.

I think the only significant effort here would be to come up with a decent human-readable file format. The LIRC format is, well, just awful; moreover, as it only records individual pulses, it is fundamentally incompatible with the current Pierogi system. I'm using a protocol-based system now, so a config file would presumably involve naming the protocol to use, then (sometimes) a manufacturer ID, (usually) a device ID, and finally a sequence of key IDs. The key IDs will also need to be mapped to the internal Pierogi button list.

I've gotten a whole lot more experience writing recursive-descent XML parsers in the last year, which folks can probably see from my other pasta products, so I'd be happy to support an XML-based file format. But I could probably do something else too, if another type of format would be preferred.