[Gtk-sharp-list] Databindig IList to a Gtk.TreeView

mlgs mlgs at arsis.net
Mon Apr 24 13:48:18 EDT 2006

On Mon, 2006-04-24 at 00:40 +0200, Philip Van Hoof wrote:
> On Mon, 2006-04-24 at 00:26 +0200, mlgs at arsis.net wrote:
> > Quoting Philip Van Hoof <spam at pvanhoof.be>:
> > > Let me know. It's a mod_svn so I can apply any type of Apache2 authent-
> > > ication (htpasswd2, etc).
> > > 
> > 
> > I see no prob here. I'm prepared to do my share of work on this one. Especialy
> > if this would have a chance to get in regular gtk-sharp TreeView (or if the
> > mainters decide what kind of Databindings they prefer).
> Know what, try to catch me on IRC and I'll give you credentials with
> commit permissions. My nickname is pvanhoof. I'm for example on the
> #mono channel (if I'm awake).

I'm not really irc person:) and currently I'm absent without permanent
internet link for next two months, but I'll see what I can do about it.

> That's for everybody who's interested in such a SVN account and/or
> planning to tryout things with the code.

is it really sane to have it outside of gtk-sharp?

> > If anything matters, I did another patch, but I'm not on my computer right now
> > so I can't send it right now, I didn't expect that childish patch would be taken
> > in consideration so soon (and if it even would).
> > Second patch is restoring the state of treeview after same datasource has been
> > applied again. Restoring position and selections. Only one problem with that
> > patch, I can't get rid of flicker in treeview on restore (redrawing start and
> > then changing position with another redraw). Doing
> > treeviewobject.GdkWindow.FreezeUpdates() and
> > treeviewobject.GdkWindow.ThawUpdates() doesn't seem to help here either (any
> > idea is appreciated). Have to look more than 15 minutes as I did so far.
> As long as this is typical for the view, I'm okay with such a patch.
> Else it might be more interesting to implement this by inheriting as a
> new type. But I'll take a look.

ok, here's the patch I talked about.
it includes ComboBox and ComboBoxEntry besides that little and still
problematic state restore on treeview (yes, in my opinion it should be
part of the main class, reasons below).

even after implementing them, ComboBox and ComboBoxEntry still had one
problem that bugged me for half of hour trying to discover the reason
(reason was you were allowing one item to few in nth_child_cb, probably
when copy/pasting code from next_cb, damn, I really hate such things).
applied model callbacks seemed to ask for item 0 when they are in fact
asking for the last. this loss of time is probably the reason why
ComboBox handling with keyboard seems problematic (works fine with
mouse, but when you press KEYDOWN for example you get SIGSEGV about
combo not being able to obtain model). But since this is more or less
proof of case, I'll be fine with it for now. any suggestion is
appreciated, this is my first gui work after 9 years of strictly console
services coding, so if you have any idea, don't hesitate because I'm
looking in the dark (kicking the fog or whatever) on this one.

another thing that bugs me is how do I know which level I'm asked on
has_child_cb. only one index, no treepath, nothing??? I would like to
make discovery there and if another IList object is on that spot also
return valid answer (one way would be handling opened and closed nodes
and iterating trough, but that seems more or less like pain in the ass).
nice example of this is xml document, where all children are also
xmlnodes, this way complete tree structure could be passed trough
datasource in one pass. (again, I would appreciate any kind of info

- reasons for treeview restore

as you see I'm applying this only in case when applied DataSource is the
same as DataSource before.

resetting selection and viewport after adding a new member goes against
any kind of HIG. well, to be truth full my software-s are always having
interaction from the operating system and one can't know when item will
be added, and destroying selections and moving viewpoint on fly is not
what one would call HIG design.

- plans for this test case

making one more interface besides IList, list that supports cursors (my
plan is having ICursor interface that points to object being binded to
controls) and change notifications which could then be used to bind form
controls directly on the selected object in IList (or as a matter of
fact any object). well that's my idea for now.

this would for example make possible to select multiple items, hit edit
and all is just plain working. at least I need that in my project.

> You may of course put a new such type in SVN once you have the
> credentials / the account (in case the feature is better implemented in
> a new type).
> > I plan to try making the same thing for Combo.
> Okay.

so, I did it;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: combobindings.patch.gz
Type: application/x-gzip
Size: 3781 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20060424/6c238817/combobindings.patch.gz

More information about the Gtk-sharp-list mailing list