Recently, I found the time.
At first, I just wanted to bring it into shape, with possibly some code restructuring and adding some features that will naturally emerge.
All my previous contacts with existing KDE apps (which were written by someone else) - namely KAtomic, KLines, KMines, KReversi - ended up being a major rewrite. I thought that I could do differently with KBugBuster.
Unfortunately, this wasn't the case! After two days of hacking I suddenly realised that I was dissatisfied with the existing API and code (to such a degree that I ended up with so much "restructuring" that I put a lot of "TODO - remove this, do another way" comments in the code. So I just started from the beginning. I didn’t throw away any old code, it has been kept for reference.
And this rewrite has had a great influence on my KDE/Qt learning curve - I started to learn the Qt model/view framework, and I learned how to use KIO (never tried it in action before - kudos to the developers, KIO rocks!).
My nearest goal is to make it generally work, which means introducing a basic GUI which permits the user to:
- Work with bugs on several servers: I started to develop a so-called "sidebar", which is a tree view containing a server list. Each server can have child items which can have arbitrary Bugzilla queries attached to them (similar to the "saved queries" feature of Bugzilla).
- Work with bugs: change their status, add comments, attachments, etc. - the usual Bugzilla activities.
Bug parsing works to some extent - I introduced a simple API for this, but didn't yet write the needed extraction routines, so it extracts only the bug ID and a short description (which is enough for me to do testing at the moment).
What doesn't work (and which I plan to address in the near future):
- What I termed as "work with bugs" above.
No comments viewing, adding, modification, etc. has yet been started. - Bugzilla login.
Currently KBugBuster can perform only those operations that don't require the user to be logged in. I need to learn some KHTML & cookies wisdom to implement this I guess.
- Make the user interface nicer and more robust
- Make the bug parsing process asynchronous
- Introduce some kind of bug caching, perhaps partial sync with Bugzilla to allow offline work and queuing actions on bugs
- Matt Rogers suggested to make KBugBuster a KPart - might be useful for embedding (e.g. in KDevelop)
- Backend classes are responsible for talking with Bugzilla servers, managing them, querying for bugs, processing received XML and so on.
- GUI classes are... well, they are GUI classes - they communicate with backend classes, ask them for info and display it upon retrieval.
And now it is time for... yes, screenshots! Since everybody loves them...
But be prepared - nothing outstanding :) Treeview and listview. Servers here, bugz there. Very simple so far. Actually, I'd say that the code is prettier than the screenshots!