Re: Minutes of the GTK+ Team Meeting - 2008-09-23
- From: "Milosz Derezynski" <internalerror gmail com>
- To: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: Minutes of the GTK+ Team Meeting - 2008-09-23
- Date: Wed, 24 Sep 2008 20:17:57 +0200
Personally if i had the choice (but i'm not into all factors and standard procedures and their motivations at Gtk+ in the past), i'd keep the API calls of GtkVBox/HBox for a really long time, and (yes) certainly past 3.0, and make them just be wrappers for the new orientation API.
In theory cleanliness and streamlinedness (?) of the API may be relevant and good to have, but in practical, people should be kept from having to constantly deal with huge efforts just to keep their apps current, so they can spend more time on actual work on their apps.
Don't misunderstand me please, I'm not saying that Gtk+ makes it "impossible" for people to focus on their apps, but i think where extra effort can be avoided it should be.
BTW such kinds of changes *could* be pinned at the frontpage of
gtk.org. I can see many people shrieking right now, but where else would you place it if you want it to be widely known? (Perhaps warnings warning about API to be deprecated, but where else aside from that if not
gtk.org/library.gnome.org?) There could even be a head section in the Gtk+ docs outlining currently ongoing plans of changes. I think developers deserve to be informed about that as best as possible.
Regards,
M.
2008/9/24 BJörn Lindqvist
<bjourne gmail com>
2008/9/24 Michael Natterer <mitch gimp org>:
> On Wed, 2008-09-24 at 11:23 -0400, Morten Welinder wrote:
>> > I don't think the minutes reflect what was said in the meeting here.
>> > My understanding was hat the H/V subclasses get deprecated as soon
>> > as the code to enable flipping in their parent classes is in SVN.
>>
>> If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then
>> it would be near-impossible to write a program to compile against both
>> 2.x and 3.x
>
> How is this different from any other deprecated function that got
> replaced by another one and will disappear in 3.0?
The only difference is that there are millions of uses of GtkHBox,
GtkVBox and friends and it would probably be very hard to get rid of
them all. Maybe it would be better to wait until 3.2 to delete them to
get application developers more time to prepare?
--
mvh Björn
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]