[Gtk-sharp-list] API cleanup for Gtk# 3.0
Christian Hoff
christian_hoff at gmx.net
Sun Jul 12 06:02:32 EDT 2009
Maarten Bosmans wrote:
>>> * 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.
>
Yes, moving these methods to AccelGroup would be a good idea. The GAPI
parser thinks they belong to Gtk.Accel as there is no "Gtk.AccelGroups"
class (the CNames start with gtk_accel_group*s*_...) This is a simple
fix (<move-node
path="/api/namespace/class[@name='Accel']/method[@name='...']">/api/namespace/object[@cname='GtkAccelGroup']</move-node>
and mark the old implementation as obsolete).
Could you file a bug report for that one, too?
>
> 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?
>
"Obsoleting" the methods is fine.
> 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.
>
That's nice, we are swamped with bug reports and other things at the
moment :-)
Christian
More information about the Gtk-sharp-list
mailing list