API cleanup for Gtk# 3.0

[mkbosmans]

I'm not shure if it's the intention to break api on going to Gtk# 3.0, but there is certainly a lot of room for improvement. Here are three examples I ran into the last couple of days.

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

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

* Gtk.Accel: there are just 2 non-obsolete methods in this class. Can they also be moved to AccelMap? In general it would be nice to remove some really obsolete stuff from Gtk#.

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.

Maarten Bosmans

[Christian Hoff]

mkbosmans wrote:
> I'm not shure if it's the intention to break api on going to Gtk# 3.0, but
> there is certainly a lot of room for improvement. Here are three examples I
> ran into the last couple of days.
>
> * 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?
> * 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.
> * 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.
> In general it would be nice to remove some really
> obsolete stuff from Gtk#.
>  
Yes, I agree. I assume all obsolete stuff will be removed in Gtk# 3.0.
We should also create a list for planned conceptual changes that will
break compatibility (like removing the  SetValue methods from the
Gtk.TreeModel interface) or file bug reports for these. Mike, what do
you think is the best way to deal with this?
> 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.

Christian
_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[mkbosmans]

Hi Christian,

thanks for your reply!

On Fri, Jul 10, 2009 at 5:33 PM, Christian Hoff<christian_hoff@...> 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  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

[Christian Hoff]

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
_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@...
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list