- Christian Reis arranged a host of electrons thusly: -
> This is a *very* interesting problem. I've not thought a lot about it,
> but it seems to stem from the fact that GtkCombo is *not* an Editable,
> but instead *wraps* one (at least it did in 1.2, and I don't think
> anybody's gone and fixed *that* one).
It's certainly had my attention for the last day or two ;) I wish
someone had fixed the problem(s) with GtkCombo, but alas, they have not.
Unfortunately, even if gtk.Combo were an Editable, it wouldn't help, as
it needs to be a CellEditable.
> That's one way to proceed, but I'm not sure this is safe to call. I'm
> afraid to say your question belongs more to the GTK+ development lists;
> I'd give that a go first, because it's more likely someone there will
> have an idea of what the best fix is. The way I see it, there are two
> approaches:
It seems to be called only during the gtk_whatever_get_type calls (which
are called at library startup time?), so it's probably not safe to call
at regular runtime, no.
> - Make your GtkCombo `look' like a GtkEditable and avoid that check.
> The problem here is that this is the first bump on the road, and
> who knows how much trouble you'll have making your Combo proxy
> everything into its inner Entry.
I can't see any way to avoid the check, unfortunately, except by hacking
the Gtk sources
> - Make the TreeView more lenient as to what it accepts as an
> editable widget.
>
> Oh, just thought of something -- have you tried passing in the combo's
> *entry* as the editing widget instead of the combo itself? That might
> work. I have no idea of how renderers are set up (having no GTK+2
> experience myself), but that might work.
Good idea! It got me past the check that was hanging me up earlier. It
still dies though, when the TreeView widget tries to reparent the
internal entry into itself. It's trying to treat the Combo as a
container, so those calls fail.
OT: I'm really impressed with the rigour that the gtk authors have applied
to making assertions at the start of all of their routines. Pain in the
arse at the moment, but very useful for debugging I have to imagine.
I've had a few other ideas that I'm chasing down. I'll mention the most
interesting one (and the one that would be the most work). I was
thinking of having a __ginterfaces__ similar to __gproperties__ and
__gsignals__ that would do what I need. I don't really know how
practical implementing such a beast would be, as I don't fully
understand how the gobject stuff is wrapped. I don't even know too much
about the C interface to python (thankfully there appear to be good
docs). It occurs to me that this might remove the need for the
GenericCellRenderer class (and it's ilk).
Does such an idea even seem palatable? I'm not sure I'd want to
undertake implementing it unless it might be incorporated into the
sources. I might be the only person who'd ever want to use it, or
something. Should I file an enhancement request in bugzilla, or...
> Offtopic question: I, too, implemented an autocomplete widget for Kiwi,
> and I was wondering if you've benchmarked your widget to see how many
> items it accepts before it gets slow. Mine takes about 800 items before
> it gets slow displaying the full like, and I added a `min_chars'
> parameter that determines how many chars need to be typed before we pop
> open the completion box.
Well, given that my widget is still in infancy, and uses an utterly
horrid (sequential search, with full string comparisons) algorithm for
finding matches, I'm not certain I'd want to take it beyond about 30 or
40 entries.
And I haven't even gone to the effort to figure out how to make the
dropdown list open programatically...
I've read some of the enhancement proposals for the combo widget, and
they look really nice, MVC based and all that. I'd really like to be
using one of those. *grin*
peace,
ah
--
The only exercise some people get is jumping to conclusions, running down
their friends, side-stepping responsibility, and pushing their luck.
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
