Anyway, this development was my first expirience with xmlrpc-c library. For those who do not knows, Bugzilla exposes own API via XMLRPC protocol so if you have the right libraries (or enough bravery to write your own), you can nicely access it without using browser (with consulting Bugzilla API documentation, of course).
I can summarize using xmlrpc-c with two words: very painful. I had to rewrite bugzilla client three times, mostly due bad xmlrpc-c documentation. The first time (maybe this shouldn't be counted) was client emerged from my playground with Bugzilla API. This client was synchronous and was pretty unusable with GUI, but was working.
Second try was with xmlrpc-c asynchronous API, and after a few days of guessing how things should work (because documentation is horribly bad in this part), I managed to get it running. At least I though it.
Somehow, xmlrpc-c asynchronous API badly manage cookie sessions so after loggin in, submitting bug wasn't posssible and Bugzilla would report how I'm not logged in. I'm not sure is this due this library or I was doing something wrong (hardly since you have only few async functions and is pretty hard to get things wrong :P) but I couldn't get it running in any way.
And, at the end, the third try was/is synchronous client with threading. Although I'm not a big fan of threading, using threads was very joyable comparing to horrible xmlrpc-c async API. Damnit, you can't even cancel requests with it, so if you try to shut down the client forcefully, you'll get assertion straigth from the library.
Asside from these internal stuff, I tried to keep client's GUI pretty minimal. When I get those bug report dialogs with tons of input fields, I lose desire to report the bug, no matter how critical it was. Few fields and let developers sort it as they like, right :). Here is the shot:
Next is to make it work together with ede-crasher, so when something crashes, users get an option to report it in the same time. And move it from the branches in the trunk, of course.