KConfEdit, KMail and OSCAR

I finally committed to CVS the new OSCAR protocol implementation. It uses libfaim from Gaim. Gaim developers have been very responsive so far, they applied some things I've sent them and were patiently answering my questions. I decided to rework buddy handling so things are in a state of flux right now. Also there's no documentation whatsoever, I'll write it once I'm happy with the api. After looking at Cornelius' KPrefs, I started working on KConfEdit again, which is going to become the KDE GUI config editor. I'm abstracting parsing at the moment. I've sat down and tried to come up with things a tool like this would need and now I'll be reworking internals to achieve those goals. So KConfEdit should:

• have a full blown undo system. You do not want to hit apply without thinking and break your KDE configs, no matter how experienced you are.
• flexible parsing system to easily adjust to the changing format,
• be able to edit remote files and copy whole configs from one master machine to a set of others,
• perform a global search & replace. Today I started working on the first two. I divided the parsable entities in all configs into three tokens Application, Group and Entry. The undo system is based on the Momento design pattern. Each of the three tokens, before allowing modification of its state, creates a snapshot of itself using Momento. Momento has one virtual function restore(), which as we all know by now, restores the state of the token from which the snapshot was taken from before the modification. A singleton UndoManager holds all Momento's and on undo simply pop's a the first momento and calls restore() on it. Tomorrow I'll finish the parser and start working on editing remote files. I also looked at KMail which I've been neglecting a little bit lately. KMail has a very bad reputation among KDE developers for having the most obfuscated code around and the most unfriendly team. Both are becoming more myths than anything, especially the latter one as I like to think that I'm not such an unfriendly guy ;) The first one unfortunately still applies, mainly because of the KMFolder inheritance hierarchy and KMMessage design. Both flawed, but we're working on it. The mix of KMime and Mimelib is also not helping. The "unfriendly team" myth is also somewhat based on a simple fact: all Open Source developers think they're amazing, with that thought they want to fix something in KMail and they don't bother to understand the code as KMail is not exactly small, commit something that seems to working and get flamed back to stoneage by one of us. Now that developer, who committed the unfortunate patch, feels insulted and blames it on the unfriendly team. The problem is that KMail was getting too frequently broken by such commits and it takes time to find all the problems once such a bogus patch is committed. So we ask people to send patches to the list before committing anything - that hurts the ego of some developers as they feel they either shouldn't have to be reviewed or don't feel like waiting for a review. If you want to be respected in the Open Source community abandon your ego because if you won't, then one of your committs will make you look like a jackass and that's all it takes to make people forget everything good you ever did. Sad, but true - do it for the fun or don't do it at all.