Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > pygtk clist usage

Reply
Thread Tools

pygtk clist usage

 
 
Ted Holden
Guest
Posts: n/a
 
      09-10-2003

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.



 
Reply With Quote
 
 
 
 
David M. Cook
Guest
Posts: n/a
 
      09-10-2003
In article <(E-Mail Removed)>, Ted Holden wrote:

> 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.
 
Reply With Quote
 
 
 
 
Ted Holden
Guest
Posts: n/a
 
      09-10-2003
David M. Cook wrote:

> In article <(E-Mail Removed)>, Ted Holden wrote:
>
>> 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



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.





 
Reply With Quote
 
Ted Holden
Guest
Posts: n/a
 
      09-12-2003
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....




 
Reply With Quote
 
P@draigBrady.com
Guest
Posts: n/a
 
      09-12-2003
Ted Holden wrote:
> 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?


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.

 
Reply With Quote
 
Emmanuele Bassi
Guest
Posts: n/a
 
      09-12-2003
* Ted Holden [2003-09-12 14:28]:

>> 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?


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.

--
Emmanuele Bassi | [ http://digilander.libero.it/ebassi/ ]
emmanuele.bassi(at)iol.it | Linux User #170621, http://counter.li.org
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738 08BD 8ECC DB8F A432 0FF4
 
Reply With Quote
 
Jamey Cribbs
Guest
Posts: n/a
 
      09-13-2003
Emmanuele Bassi wrote:
> 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.

 
Reply With Quote
 
David M. Cook
Guest
Posts: n/a
 
      09-13-2003
In article <(E-Mail Removed)>, Ted Holden 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?


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[i], 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
 
Reply With Quote
 
Ted Holden
Guest
Posts: n/a
 
      09-13-2003
David M. Cook wrote:


>> 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.


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

 
Reply With Quote
 
David M. Cook
Guest
Posts: n/a
 
      09-13-2003
In article <(E-Mail Removed)>, Ted Holden wrote:

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
retrieving CPU Usage and Memory Usage information in JAVA hvt Java 0 03-13-2007 01:09 PM
retrieving CPU Usage and Memory Usage information in JAVA hvt Java 0 03-13-2007 01:07 PM
CList double element error... Arcane C++ 7 07-11-2005 02:20 PM
Webchecker Usage - a problem with local usage Colin J. Williams Python 1 02-26-2004 12:28 AM
Need help on memory usage VS PF usage metfan Java 2 10-21-2003 01:58 PM



Advertisments