[pygtk] Simple TreeView API
Christian Robottom Reis
kiko at async.com.br
Thu Oct 7 20:58:41 WST 2004
On Thu, Oct 07, 2004 at 01:54:46PM +0200, Xavier Ordoquy wrote:
> On Thu, 2004-10-07 at 13:46 +0200, Fabien COUTANT wrote:
> > As a GTK 1.2/2.x and PyGtk 0.6/2.x programmer, I think it's worse
> > than that. I think the problem about the list widget lies in Gtk,
> > not in PyGtk. Once upon a time was the CList widget. It was limited
> > but simple and practical, and suited many needs. Using it, it was
> > simple to do simple things, it was moderately complicated to do
> > moderately complicated things, and it was impossible to do
> > complicated things.
> You should have done some support on irc about that. gtkclist caused an
> enormous amount of questions, noise and annoyances.
Even so, it was a lot less noise than TreeView. But let's be practical
here and move on towards something that *is* feasible instead of
complaining about the past.
I think Fabien's complaint is definitely valid: we need a widget that is
simple enough to be used by anyone not wanting to do rocket-science with
their rows. I've balked at the amount of questions and FAQs we get on
TreeView -- come *on*, the FAQ is *the* indication of a non-trivial API.
There are two possible solutions. One is writing directly to gtk-devel
and bringing the discussion up. Bringing it up with code in hand is
definitely going to be more prone to acceptance. It is likely that
something harnessing off TreeView's code and simply providing a simple
and unified API would be pretty easy to do and would solve 90% of the
complexity problems users face.
The other solution, perhaps interim, is to do a decent Python wrapper.
J. Barstow's proposal is a step in the right direction, but it should
really `look' like a regular GTK+ widget -- that means lowercase,
underscore-separated method names. I'd say a good attempt would be
mimicing most of what CList provided:
- Providing a list of headers to the constructor
- append()/insert() methods that takes a list of strings
- A clear() method that deletes all rows
- remove() method with removes a numbered row
- select/unselect_row() methods that take a numbered row
- set_data()/get_data() pairs and a find_row_from_data()
You'd need to find out if freeze()/thaw() make sense in this new
You could from there work on the icing, which is backgrounds, controlled
sorting, column visibility width and title control, pixmap and `special
cell' support if necessary.
I've heard Python is a good prototyping language, by the way <wink>.
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331
More information about the pygtk