On Thu, 2007-21-06 at 20:25 -0500, Federico Mena Quintero wrote: > On Tue, 2007-06-19 at 15:08 -0400, Morten Welinder wrote: > > > The application programmer has no choice in the matter and cannot > > really test with > > all kinds of themes and all kinds of versions of them. But the > > resulting crashes are > > still going to be blamed on the application and poor me. > > So the sequence goes: > > 1. User gets a crash in gnumeric-n.m, reports it. > > 2. Developer determines that the crash is in the theme engine. > > 3. Developer blacklists the theme engine; releases gnumeric-n.m+1 > > 4. User updates gnumeric, and can't run it anymore because it barfs on > that engine. He still risks crashes in other apps. > > I don't think blacklisting will work due to (4). If you require the > user to upgrade the app, then the user may as well update the theme > engine, too. > > It's better to tell the user "you should really update your theme > engine"; that will fix his problem and prevent crashes in other apps > as > well. I agree with Federico here. It is impractical to black list engines, or certain engine and theme combinations. eg. there are a lot of engines affected by this particular bug (think of all the Clearlooks forks out there), but most themes do not set the style property so nothing happens. You would either end up blacklisting engines, or a large amount of engine/theme combinations. At the same time, it is not practical to push fixes made in gtk-engines to all the forks. (I don't even know what is out there.) > It would be better to capture the thing that caused this particular bug, > and to make Manu Cornet's theme engine torturer replicate it. That way > people can run their theme engines through the torturer before releasing > them. The gtk-engines "make check" torture test tests for this since some time now (which is loosely based on Manu Cornet's theme engine torturer). Benjamin
Attachment:
signature.asc
Description: This is a digitally signed message part