On Mon, 2003-02-03 at 00:50, Havoc Pennington wrote: > I don't think blocking on GTK 2.4 is a good idea really. If GTK 2.4 > happens to come out in time, we can include GTK 2.4 in the release, > but GTK 2.4 won't be locked down soon enough to make GNOME 2.4 depend > on it. Would send our release schedule down the tubes. Why are we assuming that it's more likely for GNOME to be out on time than for GTK? Is there a specific reason why the GTK release cycle has to be longer? > We should however have a plan for using cut-and-pasted bits of GTK, > some stuff to consider: > > - this way GNOME 2.4 can be using the new file selector UI, for > example > > - if the cut-and-pasted bits are named in the gtk_ namespace, when > real GTK 2.4 comes out there will be symbol collision issues > we need to avoid. Thus cut-and-paste bits should probably be > in egg_. But policy here is required. Oh no, please no. :-) No cut and paste. GNOME 2.4 should ship with a public API that matches what the actual applications are using. It doesn't make any sense otherwise. If I am writing an app that integrates with GNOME 2.4, I don't want to be using a crappy, temporary, unstable GTK replacement API to get the right style of file selector; I want to be using the real thing, and most importantly I don't want to have to change my application again once GTK 2.4 with the "blessed" API comes out and the temporary API all of a sudden becomes unmaintained and deprecated. If we were talking of less important features, I could agree with having separate release cycles, but in the case of the file selector we are talking about a pretty basic one. I don't think GNOME 2.4 should go out with a new file selector and no API to use it. > - we need to get these 2.4 APIs tested prior to locking them down > (another reason to release GTK 2.4 *after* GNOME 2.4, so we > are sure we have all the kinks worked out of the APIs and have the > UI design we want for the GTk widgets) If the APIs are tested and work well for all the GNOME 2.4 apps, the extra API testing argument is not that strong. How many other apps out there will be testing the APIs of an unreleased GTK besides the GNOME ones? I would say not many... > - perhaps instead of cut-and-paste we should install static-only > libraries? Or even dynamic libs with -DWNCK_I_KNOW_THIS_IS_UNSTABLE > type pedanticism. Messy! :-) -- Ettore Perazzoli <ettore ximian com>
Attachment:
signature.asc
Description: This is a digitally signed message part