Helping Out:

I'll keep a (reasonably) updated list of "todo" items listed here, there will of course be an updated TODO file in the distribution, and in CVS. If you'd like to help out, pick one your interested in, and drop me an email (, to avoid duplicated efforts. Also please look over the development FAQ on this page.

TODO Items:

  • Add an "Edit/Select all", and an "Edit/Copy" option to select and copy the text in the text area to the clipboard.

  • New Pixmaps. The toolbar icons aren't too bad, but a new set would be nice, as woul an icon (and some code to set the icon would a plus too :o).

  • Anything else you can think of that would be usefull. If you find something else you'd like to add, send an email (to the list), you'll likely get a few good suggestions about how to approach what you want to do.

Development FAQ:

Q. Why don't you support earlier versions of gcc (i.e. without a "suitable" string class)

A. The string class is part of the STL (standard template library), and part of that specification is that the string class should have over loaded <, >, <=, >=, and == operators, hence these are broken, or incomplete implementations. I don't like to spend the time I have to code, working around these.

Q. Ok, so would you take a patch to add support for these broken libraries?

A. Sure, I've got nothing against compatability with a wider range of compilers. If I got a patch that handled things by doing something like:
   #ifdef _BROKEN_STRING_
   #endif /* _BROKEN_STRING_ */

Q. Wouldn't it be technically correct to setup your window/dialog classes in a class hierarchy?

A. Well, yes. However since PAddress is based in Gtk+, which already implements one, the code that would be shared across the hierarchy would be relatively small. So then the main advantage to having one would be to be able to pull some (or all) of the hierarchy through a common interface. With PAddress being a relatively small application, this isn't necessary.

Q. You don't comment your code much, what gives?

A. Quit true, much of my code has very few comments. I'm of the school of coding style that says you code, and variable names should be descriptive enough to be understood without a large amount of commenting. I've tried to comment anything that isn't clear. If you do come across something that is confusing, or unclear, send me a patch with appropriate comments. If I agree with you that commenting is appropriate, I'll include it.

Q. Some of your variables/methods/functions are named like VarialbeName, and others named along the lines of variable_name, why the inconsistence?

A. As a stric t rule, in my classes, all publicly available variables/methods/ functions, are named like VariableName. As a slightly less strict rule, my private variables/methods/functions, are named like variable_name.

Q. I don't agree with you on some of this stuff, any chance you'll change your mind?

A. Well, it's been known to happen. If you tell me clearly, concise, your opinion, and back it up, I will of course take it into account. However, an opinion given in a way bound to start a flame war, will get no attention from me. i.e. "x policy is dumb, do x like this" will get no attention, or consideration from me.