+1 for people who badly need a good GtkGrid.
If you check the list you'll see I'm constantly whining about
performance of the TreeView when you have really large datasets to
browse.
I'm wondering if the GtkGrid performs better (I see it has large
amounts of code derived from the Treeview + when I looked at that I was
stumped at how I could improve performance).
The particular case I care about is when you have say millions of rows
of data, but want to avoid loading them into any model until the user
actually wants to see them.
I found I could do this with the existing TreeView by using my own
custom model, which was great -- but then I ran into the problem that
as soon as the treeview found out how many rows of data I had it went
off and allocated a gtkrbtree (i think) big enough to hold all my data.
I'm hoping that gtkGrid avoids this problem -- guess I should go and
check out the code.
John
N. Volbers wrote:
Re: [pygtk] Wrapping Gtksheet
Hello,
I just wanted to let you know that I would be
willing to help with this.
I am in dire need of a GtkGrid/PyGrid-like
solution, and I would love to
see this included in the standard gtk+ library. As I
am not a very good
C programmer (even though I understand C code pretty
good), I could
assist in documentation and testing, especially for
the python part, so
if you need any help, please let me know.
Niklas.
Rafael Villar Burke schrieb:
> Christian Robottom Reis wrote:
>
>> On Wed, May 18, 2005 at 12:07:00PM +0000,
Philippe Collet wrote:
>>
>>
>>> I'm a beginner in the wrapping process.
>>> I'm trying to create a wrapper to use
gtksheet with pygtk.
>>>
>
> Philippe, it's great having some more people
wrapping libraries like
> crazy!. But remember that there's ongoing work to
add introspection
> capabilities to gobject, and it would make
bindings mostly automatic.
>
>> First question would be: why not work on
GtkGrid, which /has/ a wrapper
>> and will probably be less work to adapt?
>>
>>
> This is indeed a great suggestion. Philippe,
would you dare to have a
> look to GtkGrid? It could eventually get into
gtk+ itself and the
> problem would be solved at its root.
> If you're willing to hack on it here you have
some additional information:
>
> GtkGrid design document and comments thread on
gtk+ mailing list:
> http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00137.html
>
> Some more comments on gnome-db ML about inclusion
in gtk+:
> http://mail.gnome.org/archives/gnome-db-list/2004-April/msg00048.html
>
> Gtk+ team meeting where gtkgrid is mentioned:
> http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00130.html
>
> Isn't it a nice and promising project to work on?
;)
> Regards,
>
> Pachi
>
> _______________________________________________
> pygtk mailing list [email protected]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
|
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
