pygtk clist usage

[Ted Holden]

If anybody has any sort of a clue as to how to use a clist generated by
glade as a list, the 'GtkList' changed to 'GtkClist' by hand, and add input
strings using 'append' and end up seeing more than just the first character
of each line, I'd appreciate hearing from them.

 

[David M. Cook]

If anybody has any sort of a clue as to how to use a clist generated by
glade as a list, the 'GtkList' changed to 'GtkClist' by hand, and add input
strings using 'append' and end up seeing more than just the first character
of each line, I'd appreciate hearing from them.

Sounds like you are appending a string instead of a list of strings.

BTW, CList is deprecated (meaning it will go away in the next major gtk
release). ListStore/TreeView can be a bit hard to make the transition to,
though, as the documentation is rather scattered and fragmentary. Best
sources of info are

* The examples in the pygtk-demo directory.
* The FAQ: http://www.async.com.br/faq/pygtk/index.py?req=all
* The manual: http://www.moeraki.com/pygtkreference/pygtk2reference/

Dave Cook

____)/ \(____
_,--''''',-'/( )\`-.`````--._
,-' ,' | \ _ _ / | `-. `-.
,' / | `._ /\\ //\ _,' | \ `.
| | `. `-( ,\\_// )-' .' | |
|/' \' `\( \(_)/ )/' `/ `\|
` ` V V ' '


Splifford the bat says: Always remember

Don't waste time learning deprecated APIs.

 

[Ted Holden]

Sounds like you are appending a string instead of a list of strings.

BTW, CList is deprecated (meaning it will go away in the next major gtk
release). ListStore/TreeView can be a bit hard to make the transition to,
though, as the documentation is rather scattered and fragmentary. Best
sources of info are

Thanks! I'd gotten the thing to work using brackets around the strings and
was too sleepy to figure out why. Every other programming system I've ever
dealth with uses strings with append statements in listboxes and I end up
just guessing a lot with pygtk. The best info I'd been able to dig up on
listboxes was that list was deprecated in favor of clist. Documentation
for pygtk generally appears less than paper thin; if I can find any
documentation for liststore I'll try to use it...

The combination of c++, swig, python, pygtk, and zope looks like a
potentially winning ticket for the future of software development, but the
components will have to get easier to use somehow or other.

 

[Ted Holden]

David M. Cook wrote:

BTW, CList is deprecated (meaning it will go away in the next major gtk
release). ListStore/TreeView can be a bit hard to make the transition to,
though, as the documentation is rather scattered and fragmentary. Best
sources of info are...

I've been trying to take a look at the TreeView/ListStore model. I mean,
you've gotta be kidding. Who do you expect to want to try to figure that
out in order to use a simple listbox?

Other than that, I'm seeing a conceptual problem with the pygtk
documentation is that it appears to all be oriented towards coding gtk
objects by hand.

In real life, most people are going to want to use glade to design gui's,
and this is not laziness on the part of programmers. Having the gui
sitting there in an XML file is a hell of a neat thing. The application
I'm working on, which works at this point, used to look like about 3000
lines of code in a Tcl/Tk version, in which Tk code was wound in and around
app code so thoroughly that it was difficult even for me to read. The
glade/pygtk/swig version looks like about 400 lines of code which is very
easy to read and work with; again, all the gui code is sitting there in an
XML file.

The idea of coding guis by hand is probably unacceptable to most people at
this point.



. . , ,
____)/ \(____
_,--''''',-'/( )\`-.`````--._
,-' ,' | \ _ _ / | `-. `-.
,' / | `._ /\\ //\ _,' | \ `.
| | `. `-( ,\\_// )-' .' | |
,' _,----._ |_,----._\ ____`\o'_`o/'____ /_.----._ |_,----._ `.
|/' \' `\( \(_)/ )/' `/ `\|
` ` V V ' '


Splifford the bat says:

Don't throw the old stuff away,
until the new stuff works....

 

[P]

David M. Cook wrote:





I've been trying to take a look at the TreeView/ListStore model. I mean,
you've gotta be kidding. Who do you expect to want to try to figure that
out in order to use a simple listbox?

True, though I do think the flexibility is required. No free lunch and
all that. Examples always help:
http://liw.iki.fi/liw/texts/gtktreeview-tutorial.html

Pádraig.

 

[Emmanuele Bassi]

* Ted Holden [2003-09-12 14:28]:

I've been trying to take a look at the TreeView/ListStore model. I mean,
you've gotta be kidding. Who do you expect to want to try to figure that
out in order to use a simple listbox?

I did, and I do. In C, Python and (yuk) Perl.

The basics of the MVC (model/viewer/controller) paradigm are fully
graspable in less than 15 minutes (at least, that's how much I had to
spend learning them - and I did not know anything about MVC). The power
of a MVC system, with customisable models and renderers outweights the
underlying complexity. Alas, the TreeView/TreeModel pair isn't quite as
fast as CTree/CList, so you need some tricks when dealing with large
models, but for simple listboxes, I've never seen any performance
problem whatsoever.

Creating a simple listbox takes no more than 20 lines of code, callbacks
not included. You could create a class that covers everything you might
want, and reuse it (or submit it to the pygtk mailing list) thoughout a
project or in multiple projects.

Other than that, I'm seeing a conceptual problem with the pygtk
documentation is that it appears to all be oriented towards coding gtk
objects by hand.

I do my coding exactely like this. I prefer this way, since Glade it's
not flexible enough for me.

The idea of coding guis by hand is probably unacceptable to most people at
this point.

Having a(nother) library to depend on when distributing an application,
and an XML file sitting around in order to create the UI, may be
unacceptable to many people. Your point is?

Bye,
Emmanuele.

 

[Jamey Cribbs]

Alas, the TreeView/TreeModel pair isn't quite as
fast as CTree/CList, so you need some tricks when dealing with large
models, but for simple listboxes, I've never seen any performance
problem whatsoever.

And performance seems to get better. About 6 months ago when I was
first working on what would become MojoView, I tried using a
Liststore/Treeview combination to display the data in grid form, but it
was just too slow. That's the main reason I went with a CList, even
though I knew it was deprecated.

Today, I spent some time pulling out the CList code and slapping in a
Liststore/Treeview, using the latest Gtk2 and pygtk, to see if
peformance has improved...and it has! The Liststore/Treeview combo is
now almost as fast as the CList (at least in my test app), except for
one thing. When ever I populate a sorted Liststore the SECOND time, it
takes a lot longer than it did the first time. If I can figure out this
last problem, I intend on replacing the CList in Mojoview with a
Liststore/Treeview.

For some example (not necessarily pretty, but it works!) code that uses
pygtk, including CLists, go to http://www.netpromi.com/mojoview.html.

Yes, sometimes I think the new MVC model is WAY overkill for what I
need, but, since CList is deprecated, it's the only way to go.

Creating a simple listbox takes no more than 20 lines of code, callbacks
not included. You could create a class that covers everything you might
want, and reuse it (or submit it to the pygtk mailing list) thoughout a
project or in multiple projects.
I do my coding exactely like this. I prefer this way, since Glade it's
not flexible enough for me.

I agree with you. I've tried Glade and it is cool, but for some reason,
I like hand-coding my gui's also. If you put everything in classes that
you can reuse, it doesn't really get any more spagetti-like than using
Glade.

 

[David M. Cook]

I've been trying to take a look at the TreeView/ListStore model. I mean,
you've gotta be kidding. Who do you expect to want to try to figure that
out in order to use a simple listbox?

It's not too bad. For a simple list there is only an extra step of adding
the TreeViewColumns. Say for a simple non-editable list with column types
(str, int, int):

# untested code
titles = ('foo', 'bar', 'baz')
coltypes = (str, int, int)
store = gtk.ListStore(*coltypes)
treeview = gtk.TreeView(store)
ncolumns = len(titles)
for i in range(ncolumns): # or "for i, title in enumerate(titles)" in 2.3
cell = CellRendererText()
viewcol = gtk.TreeViewColumn(titles, cell, text=i)
treeview.append(viewcol)

It's not too hard to create a function that appends the TreeViewColumns. A
good way to do this is to encapsulate your domain specific info (such as
type) in a Column object and pass a list of Column objects to your
TreeViewColumn appending function.

Other than that, I'm seeing a conceptual problem with the pygtk
documentation is that it appears to all be oriented towards coding gtk
objects by hand.

In real life, most people are going to want to use glade to design gui's,
and this is not laziness on the part of programmers.

Right now about all glade does for you with respect to a treeview is put it
in a ScrolledWindow and allow you to set some TreeView properties and signal
handlers. However, most of TreeView usage deals with the associated objects
like TreeViewColumn, CellRenderers, stores, selections, etc., and these
glade does not help with.

And, yes, I think glade should do something to make it easy to set up simple
lists and trees, but programmer laziness goes both ways ;}. glade-3 is
still under active development, so I think anyone who would like to create a
more comprehensive TreeView "configurator" has a good window of opportunity
right now.

Having the gui
sitting there in an XML file is a hell of a neat thing. The application
I'm working on, which works at this point, used to look like about 3000
lines of code in a Tcl/Tk version, in which Tk code was wound in and around
app code so thoroughly that it was difficult even for me to read. The
glade/pygtk/swig version looks like about 400 lines of code which is very
easy to read and work with; again, all the gui code is sitting there in an
XML file.

Agreed. However, the way I use TreeViews in my own app is a lot more
dynamic than this allows for (I'm reading a lot of tables from a database
and setting up TreeViews dynamically based on metadata), so I would end up
setting up my TreeViews programmatically anyway.

The idea of coding guis by hand is probably unacceptable to most people at
this point.

Glade still helps with the layout scutwork, it just doesn't set up the
TreeView columns and other internals yet.

Don't throw the old stuff away,
until the new stuff works....

It works, but the glade folks haven't caught up yet (AFAIK).

Dave Cook

 

[Ted Holden]

David M. Cook wrote:

Agreed. However, the way I use TreeViews in my own app is a lot more
dynamic than this allows for (I'm reading a lot of tables from a database
and setting up TreeViews dynamically based on metadata), so I would end up
setting up my TreeViews programmatically anyway.


Glade still helps with the layout scutwork, it just doesn't set up the
TreeView columns and other internals yet.

In terms of pure functionality you'd have to like Tk better than glade and
Pygtk at this point, nonetheless the idea of XML usage for guis is so
compelling that I'd just as soon go with glade and pygtk and wait for the
functionality to catch up.


Ted

 

[David M. Cook]

In terms of pure functionality you'd have to like Tk better than glade and

Tk is more mature and has much better documentation, but it doesn't have
anything like an editable multi-column tree widget with an MVC architecture.
The MVC architecture allows you to switch stores in the save view, or load
the same store into multiple views.

Pygtk at this point, nonetheless the idea of XML usage for guis is so
compelling that I'd just as soon go with glade and pygtk and wait for the
functionality to catch up.

There's wxglade,

http://wxglade.sf.net

but I don't know anything about how the generated "xrc" files are used. And
I think Qt has something similar. I looked in vain for a similar free tool
for Java/Swing, though there is a commercial tool:

http://www.jeasy.de/purchase.htm

Dave Cook