Monday, December 6, 2010

Duality SVN - Gathering momentum

Things have been getting a bit quiet here over the past few days, so let's dust off the cobwebs here!

Over the past week, I've been slowly working away on getting the Duality SVN UI up and running. Unfortunately, things have been going a bit slower than hoped (so this post does NOT announce the first public release as tentatively advertised before), as I ended up getting stuck for a few days trawling so-so documentation (and dissecting example scripts) before finally figuring out the necessary code to get a few core components working. In particular, most of this work all just went towards...
The "status list" widget.

(NB: The colour of the "external" status indicator is something I'm still playing with. I've been trying to get it as invisible as possible using the "predefined" colours as I really don't care about such entries much. Anyways, on second thought, the yellow seems to be a bit too loud still, yet grey makes it too similar to "Unversioned" which I want discrete yet still visible. Hmm...)

Here's a brief summary of "learnings" from this process:
1) The base widget for the "list" here is actually a QTreeView.
Yes, there isn't any hierarchical stuff going on here and in all standard terminology it would be a "list", but QListView's can only have a single column. Bleh!

2) To get what I want, I ended up implementing my own QAbstractItemModel subclass.
2.1) Using the provided "standard model" might've also been possible, but I'm still not sure how this interacts with QStandardItem for sure. On one hand, QStandardItem sounds like it just fills in one cell in the table, while on the other hand, there is talk of "child tables" with "single columns/lists". All of which is quite confusing when all I want is a list with 3 columns corresponding to attributes of the items in the list represented by rows.
2.2) Implementing my own let me have some control over how I clobbered stuff together for the view, and this also allowed me to use this as an actual storage model that can also interact with Qt.
2.3) Finding examples showing how to implement the callbacks required by the model but in a way that provides the capabilities that I need from it (and with sufficient complexity/functional capability) is difficult.
2.4) QModelIndex is an euphemism for "cell identifier wrapper". It also has some wacky "internal pointer" stuff, though I've chosen to ignore it for now as I can already get things working this way.
2.5) index() and data()is the key callbacks where most of the interesting stuff happens (especially the later, which is called to retrieve every aspect of a cell). All the other callbacks you have to implement are just boilerplate, in case you have a tree...
2.6) When adding/removing items to your model, you must wrap your actions within a pair of begin/end callbacks specific to the action you're doing, just like in OpenGL. The main complication here is the indices you need to supply, though that's quite nicely explained in the docs for a change.
2.7) I need to write a "big picture" tutorial on how this all works sometime...

3) The toolkit has quite a few column resizing modes, but sadly misses one of the most important IMO: a combination of "stretch" and "interactive" for the first column (or even better, a setStretchFirstSection() to compliment the setStretchLastSection()). As it stands now, I might have to override and implement my own resizing callbacks to get this working

4) PyQt is substantially better than wxPython.
This toolkit has a more robust design, with strong ingrained MVC architecture in an OO-ish way. Also, it seems to be better maintained - 4.7 (original version I was using) had a bug that caused a crash on exit whenever the list models were used, but 4.8 (version I upgraded to after reading about this bug being fixed in May?) had fixed this.


Anyways, hopefully now I shall be able to gather momentum and get this thing operational soon. Until next time, adios!

No comments:

Post a Comment