pygtk clist usage

Discussion in 'Python' started by Ted Holden, Sep 10, 2003.

  1. Ted Holden

    Ted Holden Guest

    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.
     
    Ted Holden, Sep 10, 2003
    #1
    1. Advertising

  2. In article <>, 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.
     
    David M. Cook, Sep 10, 2003
    #2
    1. Advertising

  3. Ted Holden

    Ted Holden Guest

    David M. Cook wrote:

    > In article <>, 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.
     
    Ted Holden, Sep 10, 2003
    #3
  4. Ted Holden

    Ted Holden Guest

    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....
     
    Ted Holden, Sep 12, 2003
    #4
  5. Ted Holden

    Guest

    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.
     
    , Sep 12, 2003
    #5
  6. * 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
     
    Emmanuele Bassi, Sep 12, 2003
    #6
  7. Ted Holden

    Jamey Cribbs Guest

    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.
     
    Jamey Cribbs, Sep 13, 2003
    #7
  8. In article <>, 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, 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
     
    David M. Cook, Sep 13, 2003
    #8
  9. Ted Holden

    Ted Holden Guest

    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
     
    Ted Holden, Sep 13, 2003
    #9
  10. In article <>, 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
     
    David M. Cook, Sep 13, 2003
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. metfan
    Replies:
    2
    Views:
    4,863
    Robert Olofsson
    Oct 21, 2003
  2. Colin J. Williams

    Webchecker Usage - a problem with local usage

    Colin J. Williams, Feb 25, 2004, in forum: Python
    Replies:
    1
    Views:
    555
    Colin J. Williams
    Feb 26, 2004
  3. Arcane
    Replies:
    7
    Views:
    386
    Victor Bazarov
    Jul 11, 2005
  4. hvt
    Replies:
    0
    Views:
    1,220
  5. hvt
    Replies:
    0
    Views:
    1,497
Loading...

Share This Page