[Gtk-sharp-list] Ways of supporting complex data binding in TreeView

Chas chastamar at yahoo.com
Sat May 28 08:07:18 EDT 2005


> > Do you think such a feature cannot be integrated
> to
> > Gtk# before the 3 issues you've mentioned are
> solved,
> > or do you just not see it as a priority?
> 
> 
> The ability to implement GInterfaces and override
> virtual methods would
> absolutely help with implementing a pure C#
> TreeModel implementation to
> allow for nice and easy data-binding. However, it
> would still be
> possible w/o it. You can actually look at the gtk#
> source for a
> TreeModel implementation (NodeStore). One issue if
> you look at
> NodeStore, is that the managed bit doesn't implement
> TreeModel, and this
> ends up creating a lot of interesting issues, like
> the requirement of
> NodeSelection, NodeCellDataFunc, and (somewhat)
> NodeView...

Of course. I meant "cannot be integrated" as in "would
currently have to be too ugly to be integrated".

> I think all of it is a priority, but I absolutely
> think that working to
> allow *all* GInterface implementations gives you a
> lot more than writing
> one-off hacks to implement a single GInterface
> once...

Okay, I understand.

The question of which data-binding way to go is still
viable however, whether the TreeModel itself would be
100% managed or not. If you have any additional input
on that, I'd be happy to hear. (As you said, both ways
are suboptimal, so I'm afraid maybe both ways would
have to supported to allow for different scenarios
with different requirements.)

Anyway, thanks for your response - I'll reconsider;
indeed, maybe waiting with this till it's possible to
do it in 100% managed code would be a smarter move.

Chas

> --Todd
> 
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


More information about the Gtk-sharp-list mailing list