On Tue, 7 Mar 2006, Federico Mena Quintero wrote: > On Tue, 2006-03-07 at 15:39 +0000, Bill Haneman wrote: > > > Since we're now in code freeze for 2.14, shouldn't we turn off the > > critical warnings behavior in gnome-session now? > > They'll turn themselves on automatically when the version number > reaches .14; they are on in .13 (they are based on even/odd).
By the way, shouldn't that be enabled/disabled using configure/Makefile/preprocessor magic instead of parsing the version number? > > There are lots of places where this causes unnecessary crashes, > > particularly in gail and at-spi. While we want to fix them eventually, > > it's made accessibility pretty much DOA in 2.13 so far. > > A critical warning is not some annoying spew in your console which you > can ignore; it is an indication that something has gone HORRIBLY wrong > and you should fix it immediately. It is not a faint light that says > "check engine", it is a big siren screaming, "HOLY SHIT, SOMEONE PUT > SUGAR IN YOUR GAS TANK". In many cases it's a false alarm. Something that should not have marked as such in the first place. From my experience with Pango modules recently, one major cause of these false alarms are g_return_if_fail()s. It's important to differentiate between some unusual but perfectly valid failure of something (like failing to lock a font face, because the font file may have been removed), and invalid input from the user. With former, you may want to do a g_warning and return, only with latter one should use g_return_if_fail. In other words, you should use g_return_if_fail in cases that upon seeing the crash, the developer has something to fix. This is not quite the case when font locking fails :) > Federico --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
