|
paintlib grows and lives through the contributions of many people. Because
of this, I have set up a mailing list for discussions about paintlib.
You can use this mailing list to ask for help, to submit bug reports and
fixes, and to discuss additions to the library. To subscribe to the mailing
list, send an empty email to paintlib-subscribe@egroups.com.
You can also browse the list archives by going to http://www.egroups.com/group/paintlib.
(Please don't send images or tons of code to the mailing list. If these
are relevant, please send them to me first: uzadow@cs.tu-berlin.de.)
There's also a project set up at sourceforge (http://www.sourceforge.net/projects/paintlib/)
Contributing Code
paintlib is far from complete. I will implement new features as time
permits, but since Ver 1.3 or so, most new features have come from other
contributors. (This is really encouraging and probably the reason I still
support paintlib). There are several ways to contribute code. In the order
of the amount of work they cause me:
- You can get write access to the cvs repository at sourceforge and
upload the changes yourself. Although this makes things very easy for
me, I can't give everyone write access or we'd soon have a trashed repository.
So only those people get write access who I think know what they're
doing. That usually means submitting code in one of the other ways for
a while first.
- You can submit unix-style patches through the sourceforge patch manager
that I can then integrate into the main development library.
- You can send me your complete paintlib source directory tree including
the cvs sudirectories so I can use cvs to merge the changes. This
is probably what most people can easily do.
- You can just send code snippets, but you'll probably get mail back
asking for the cvs subdirectories because merging code takes time and
is pretty boring. This is true even for small changes!
Some points:
- Make sure you've got a current version of paintlib from the sourceforge
cvs repository before you submit stuff. Everything else means major
merging hassles.
- If you think there might be design issues or if it's a large change,
present your idea and ask for input on the mailing list. This kind of
'design review' helps you avoid a lot of work if your code would otherwise
be rejected because of formal or other problems.
- Avoid using tabs in code you send to me. There's no standard tab width,
so your code will come out looking extremely unformatted on other people's
machines.
- You can document your code by adding lines starting with //! in front
of public and protected function headers or class declarations. These
lines are recognized by the documentation generation system I use, so
they'll appear in the reference section of the docs automatically.
- For new features, add an automated test to pltester.cpp that makes
sure this feature stays working. For bug fixes, add a corresponding
test that fails if the bug is there and works if it isn't. These tests
make sure that we don't break anything when we add more features to
the library and redesign internals.
- There's one other thing I have to mention because it's caused problems
in the past: If you'd like to contribute stuff to paintlib, please make
sure it's free of copyrights of other people. To avoid complications,
the core paintlib library will need to stay (c) Ulrich von Zadow. I
commit to supporting paintlib as open source software for as long as
I can, but having parts of the code copyrighted by different people
- all of whom I'd have to ask if a word changes in the terms of use
- would generate too much hassle. (If you can't live with this arrangement,
you can always submit code for inclusion as a sample.)
There is a ToDo-List that I try to keep current on sourceforge under
'Tasks'.
Bug reports
If you think you've found a bug, you have several options:
- Fix it and send me a patch. This is your best way of getting a stable
paintlib quickly. It really is - bugs are fixed whenever we think it's
fun to fix bugs. Patches are applied immediately.
- Fix it and don't send me a patch. This is your best way of getting
a version of paintlib that's incompatible with the version we maintain
here. As paintlib changes and features are added, you'll have to reapply
your changes regularly to stay current. Good luck.
- Add a bug report to the bug tracking system at sourceforge. Try to
make sure it's really paintlib's fault before you do this, however.
- Ask on the mailing list.Of course, that means that if it really is
a bug, someone will have to add the bug report to the bug tracker anyway...
It helps a lot if you add a test case to pltester.cpp that reproduces
the bug. The section below about 'asking for help' applies to bug reports,
too: We can't diagnose a problem if we don't have clear description.
Asking for Help
I welcome emails, and I really try to answer each email. However, there
are several things you can do to make my job easier. The first is to send
the help request to the mailing list. Sometimes (often), other people
know more about specific areas of the library than me, and in that case,
you will probably get a better answer by asking on the list. In addition,
a lot of help requests (not all) are completely vague, so all I can do
is reply with questions in return because I don't know what the problem
is. So if you want a clear answer the first time, please:
- tell me what compiler you're using and what system you're compiling
paintlib on (including version numbers),
- try to compile and link the example programs first,
- if you get compiler or linker errors, copy the first few error messages
into the mail and
- if you get asserts or exceptions, copy the message and the call stack
into the mail.
Also, if you can't decode a specific picture, you might want to attach
it to a private email to me. Don't do this, however, if it's
large(>500 kb), since I pay for download time.
Oh, and try not to ask questions that are answered in the documentation.
But if you've read this far, that probably isn't going to be a problem
;-).
Feature Requests and Ideas
The mailing list is the right place for discussions of this sort. Don't
be surprised, however, if your feature request is answered by me saying
"great idea, why don't you implement it" or something similar.
I do this in my spare time...
|
|