|
|
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
(petew@linuxstart.com), 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_
...
#else
...
#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.
|
|
