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/cla...@name='Accel']/meth...@name='...']">/api/namespace/obje...@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 _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
