Rich, I’m sorry that my blogging system doesn’t support comments, but the sad fact is that I probably wouldn’t check my comments anyways. :-(
Anyways, as hausi has pointed out, your aRts 1.1 suggestion doesn’t help if you’re trying to avoid glib, because it turns out you’re more or less linking it in statically. You can see the glib copy yourself in the gslglib* files on WebCVS. I have even gone and made sure that the files listed were from ARTS_1_1_BRANCH. ;-).
I think the conclusion I’m trying to point out is that if you make a multimedia system with any kind of C bindings or C core, you will end up doing one of three things:
- Use glib, since it is available and by now very well-tested. It would be advisable to not fork the library, since then you lose security updates and bug fixes.
- Avoid glib, and reimplement what you need yourself, poorly.
- Avoid any code construct even resembling anything from glib, resulting in either no MM framework, or a very lame one.
Of course, we could create or use a framework that is pure C++, such as NMM, but that seems to me to be a step to make KDE incompatible simply out of spite, which I don’t think would be good for the users of KDE.