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 email with the word subscribe in the body to paintlib-request at c-base.org. List infos, are at https://www.c-base.org/c-lists/listinfo/paintlib. Archives are at http://www.c-base.org/mailinglists/paintlib/. (Please don't send images or tons of code to the mailing list. If these are relevant, please send them to me first: u.zadow@gmx.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, lots of 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 via email that I can then integrate into the main development library.
  • You can just send code snippets, but you'll cause lots of work for me that way, which - if it's not a change I think is extremely important - I simply won't do. 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 for me.
  • 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.
  • If you'd like to contribute stuff to paintlib, please make sure it's free of copyrights of other people.

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.
  • Ask on the mailing list and hope someone else does the work for you.

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. 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:

  1. tell me what compiler you're using and what system you're compiling paintlib on (including version numbers),
  2. try to compile and link the example programs first,
  3. if you get compiler or linker errors, copy the first few error messages into the mail and
  4. 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).

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.