Re: GNOME Namespace Management - ARC & GNOME



>> I don't expect the GTK developers to avoid breaking apps that were
>> already broken.  That wouldn't be fair or realistic.
>>
>> Once GTK publishes an API, however, I expect it to never break.  Most of
>> the minor stuff I see where it does is because developers don't want the
>> "ugliness" of having two sets of functions that do _almost_ the same
>> thing, that sort of stuff.
>
> This whole discussion would be a lot easier if you actually said what
> you've seen. I deal with 99% of the GTK+ API from gtkmm and I only
> remember the following:
>
> 1. ABI breakage once in private (though not well-documented as private)
> and rarely-used API.

By the way, that was the change to the API of some keybinding (also known
as action) signals.

> 2. API breakage once which did not cause ABI breakage, because the API was
> just changed to match the ABI. That was the change to the type of a
> CellRender vfunc's parameter.
>
> 3. The "construct-only properties" correction of runtime behaviour, that's
> been discussed fully already.
>
> In both cases, very very little code was affected.
>
> I am talking about traditional library ABI, because I think you are too.
>
>>  My only advice there is to just suck it up,
>> provide both sets of functions, and clean up the cruft in the next major
>> release.
> [snip]
>
> This is exactly what GTK+ does. They don't need more persuading.
>
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>


Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]