[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