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.


Have you considered doing that? (And if you mentionned that already: have you considered doing the paragraphs thing ;-) ? )

By Maksim Orlovich at Sat, 08/02/2003 - 16:22

Sure, it's one of the reason I've chosen the Momento pattern. The undo mechanism is IMHO really well design at this point and allows for all kinds of weird stuff. All persistand undo would take is creating a destructor in the Momento class that saves its state to a file given by the UndoManager. Then on startup UndoManager reads that file back and creates from it the list of Momento's which all look like they did before the last closing. It's definitely on my todo list and the hardest part of that implementation is coming up with the format of the file in which Momento's store they state as the implementation would be trivial.
As far as nice formatting of my blog entries goes, it's pretty much a lost cause. I usually write them right before I go to bed and can't be bothered with formatting, grammar or even spelling ;)

By zack rusin at Sat, 08/02/2003 - 17:27

I guess you mean memento. :)

By KDE User at Sat, 08/02/2003 - 18:39

heh, I meant that it's based on memento but I called the class Momento because it's a little different. The basic idea is the same (hence the similar name) but the implementation is a little different. Because tokens are not really commands and we care about their state I eliminated the Originator which in the original pattern creates the mementos and it our case was simply redundant. The Tokens themselves serve the purpose of the Originators on which some actions are performed :)

By zack rusin at Sat, 08/02/2003 - 19:56

Please think about support for diffing two configs,


By KDE User at Sat, 08/02/2003 - 16:51

Definitely, once I get the parser working it will be trivial as all it will take is the direct comparison of Application tokens. (ApplicationToken holds GroupToken's and GroupToken's hold EntryToken). Like I said the basic idea right now is to design api to make it easily as extensible as possible.

By zack rusin at Sat, 08/02/2003 - 17:19