> > 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 _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
