Re: Adding error reporting to GtkFileChooser
Mark McLoughlin <[email protected]>
| Newsgroups | gmane.comp.gnome.language-bindings,gmane.comp.gnome.gtk+.devel.general |
|---|---|
| Message-ID | <1078389805.4200.15.camel@laptop> |
Hi, On Wed, 2004-03-03 at 20:32, Jody Goldberg wrote: > On Wed, Mar 03, 2004 at 08:21:04PM +0000, Mark McLoughlin wrote: > > Hi, > > > > On Wed, 2004-03-03 at 16:45, Owen Taylor wrote: > > > On Tue, 2004-03-02 at 15:48, Federico Mena Quintero wrote: > > > > Some functions in GtkFileChooser don't report errors back to the caller: > > > > > > We are hard API/ABI frozen at this point, but this is by policy, not > > > by necessity, so if we need to make an exception we can make an > > > exception, with the downsides: > > > > There is no question in my mind that this change would delay the GNOME > > 2.6.0 release date. > > > > Its down to you guys to make the call, but I would urge you to just > > suck it up and stick with the freeze. > > I'll disagree here. I'd rather slip the gnome release and get this > api correct than live with the mess until gtk-3.0 in the star trek > future. The GTK+ team has set the date of March the 8th for 2.4.0 for the sole purpose of not delaying the GNOME 2.6.0 release. What I'm trying to point out is that if the API changes at this point it will delay the GNOME release even if the GTK+ release meets its target date. At the very least, we need a decision on this. (Of course, as a hacker, I want sane APIs too. So, if I thought it was clearly critical important for this API to be fixed by breaking the API, I would hold my tongue. But I've followed the discussion closely and haven't been convinced that its a clear cut argument. But that's not my call to make.) Cheers, Mark. _______________________________________________ language-bindings mailing list [email protected] http://mail.gnome.org/mailman/listinfo/language-bindings