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

[Maarten Bosmans]

Hi Christian,

thanks for your reply!

On Fri, Jul 10, 2009 at 5:33 PM, Christian Hoff<christian_hoff at gmx.net> wrote:
> mkbosmans wrote:
>> * 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?

https://bugzilla.novell.com/show_bug.cgi?id=521359

>> * 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.

https://bugzilla.novell.com/show_bug.cgi?id=521360

>> * 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.

No, this is a Gtk# issue. The Gtk.Accel.Map* methods are marked
obsolete and are superseeded by Gtk.AccelMap.*. Note that both
versions point to the same C function.

My line of thinking was that in 3.0 the obsolete methods would be
removed and then there are just 2 methods left in Gtk.Accel. IMHO it's
not worth keeping the class around for two static members and moving
them to e.g. Gtk.AccelGroup would simplify the api.

>> 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.

If I supply patches that add an overload to the current methods, would
marking the current ones obsolete be regarded as a compatibility
break, or is obsoleting OK?
I think this would provide the best upgrade path. Developers could use
the last 2.x release and it would still work, but after changing their
code to remove all the obsolete warnings, the code would run fine on
3.0.

BTW, I'm on holiday for the next two weeks and will try to provide
patches after that. If anyone wants have a go at making a patch, that
fine too. In any case it would be nice to have some guiding comments
on the bug reports, to steer the patches in the right direction.

Maarten