Hi Christian, thanks for your reply!
On Fri, Jul 10, 2009 at 5:33 PM, Christian Hoff<[email protected]> 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 _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
