[Gtk-sharp-list] API cleanup for Gtk# 3.0

[Christian Hoff]

mkbosmans wrote:
> I'm not shure if it's the intention to break api on going to Gtk# 3.0, but
> there is certainly a lot of room for improvement. Here are three examples I
> ran into the last couple of days.
>
> * AccelGroup.ConnectByPath(string accel_path, IntPtr closure) and other
> connect/disconnect methods. I'm not shure how to generate a closure pointer
> in C#. The method probably should accept a delegate.
>   
Hum, this sounds like a bug in Gtk# that we can fix without breaking 
compatibility. Could you file a report?
> * Widget.Path has the signature void Path (out uint path_length, out string
> path, out string path_reversed). At least the length parameter can go and
> may be even the reversed path so the normal path string can be the return
> value, as to avoid ugly out parameters.
>   
Some as above. I'm wondering why the C function expects the length of 
the path as parameter? Both strings should be NULL-terminated. We 
probably have to add a custom implementation of that method.
> * Gtk.Accel: there are just 2 non-obsolete methods in this class. Can they
> also be moved to AccelMap? 
Gtk# is just a wrapper around Gtk+. You could file a bug report upstream 
if you want to pursue it.
> In general it would be nice to remove some really
> obsolete stuff from Gtk#.
>   
Yes, I agree. I assume all obsolete stuff will be removed in Gtk# 3.0. 
We should also create a list for planned conceptual changes that will 
break compatibility (like removing the  SetValue methods from the 
Gtk.TreeModel interface) or file bug reports for these. Mike, what do 
you think is the best way to deal with this?
> If there is consensus on the list that these (and there are probably more
> too) things should be fixed, then I shall file bugzilla entries for them and
> try to produce some patches.
>   
That would be just nice for the first two binding issues you mentioned. 
But please don't provide patches that will break compatibility as we're 
not sure yet when we can switch to a 3.0 dependency for trunk. If Gtk+ 3 
were to languish unreleased, we may release Gtk# 2.18 from trunk first.

Christian