Re: Blacklisting themes?
On Wed, 2007-04-07 at 01:48 +0200, Milosz Derezynski wrote: Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 I'm not sure this ever got a proper audit and all themes in general could need one. s/themes/engines/ ! And none of the engines in gtk-engines is exporting anything currently. Might not be the ideal solution to mark all functions as internal separately, but it _does_ work. *And* as my comment in the bug states, the engines in gtk-engines do get tested for this during make check. If you want to do something in this area, get all the non gtk-engines engines fixed ... (eg. UbuntuLooks) Does there exist a unittest suite for theme engines (and yeah i gues i just volunteered to write one if it doesn't. heh :) ? Well, maybe it does not go trough as a unittest (I don't know what the real definition is) but we *do* have a test. And a large part of the code paths _are_ tested [1] (except for smooth). Benjamin [1] https://buildbot-gnome.igalia.com/gnomebuild/gtk-engines/lcov/ signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 I'm not sure this ever got a proper audit and all themes in general could need one. Does there exist a unittest suite for theme engines (and yeah i gues i just volunteered to write one if it doesn't. heh :) ? On 6/25/07, Morten Welinder [EMAIL PROTECTED] wrote: I was thinking more of gtk+ blacklisting the theme, but nevermind that. 4. User updates gnumeric, and can't run it anymore because it barfs on that engine. He still risks crashes in other apps. Not quite. Gnumeric starts with default theme, looks strange, but works. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Wed, 2007-07-04 at 01:48 +0200, Milosz Derezynski wrote: Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 I'm not sure this ever got a proper audit and all themes in general could need one. Hmm, didn't that get fixed? At least for the well-known themes? Does there exist a unittest suite for theme engines (and yeah i gues i just volunteered to write one if it doesn't. heh :) ? AFAIK there's just Manu Cornet's torture test. It's not a unit test, but more of a does the engine crash when it gets passed funny values?. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
I was thinking more of gtk+ blacklisting the theme, but nevermind that. 4. User updates gnumeric, and can't run it anymore because it barfs on that engine. He still risks crashes in other apps. Not quite. Gnumeric starts with default theme, looks strange, but works. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
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. Well, but that still keeps the problem of countless dups in Bugzilla and bad reputation. I support the idea of blacklisting as this could be some efficient measure for quality control, but only if the blacklisting doesn't happen in the application, but in GTK+. Blacklisted themes would by detected by the MD5, SHA256, whatever hash over their gtkrc. Distributors would be encouraged to frequently backport our blacklist into their current GTK+ package. The blacklist even could be packaged separatly to make upgrades cheap. Just my 2 cents... Ciao, Mathias -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
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 signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Fri, Jun 22, 2007 at 02:04:17PM +0200, Benjamin Berg wrote: 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. I don't think Morten's intent was to handle the blacklist at the application level. A more practical approach would be a bugbuddy extension that would compare the current theme engine and version against a central collection of known bad engines, aka a black list. Then a user could be notified at the time of the crash that the right solution is to stop using that theme. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On Fri, 2007-06-22 at 09:20 -0400, Jody Goldberg wrote: I don't think Morten's intent was to handle the blacklist at the application level. A more practical approach would be a bugbuddy extension that would compare the current theme engine and version against a central collection of known bad engines, aka a black list. Then a user could be notified at the time of the crash that the right solution is to stop using that theme. This is certainly a nice idea --- although then people would need a newer version of BugBuddy ;) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
2007/6/19, Morten Welinder [EMAIL PROTECTED]: 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. The usual way to prevent this is to advocate fixed versions (or backported patches) to the distributions. I think it's the only valid way too, since as you note, the application programmer has no choice and should not have to care about the versions. It's really the distribution who has the responsibility to provide fixed versions of software. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
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. 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. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Blacklisting themes?
In light of bug 438456, is there (or should there be) a way to blacklist a certain theme engine for a certain version range? Bug 438456 causes memory corruption in any gtk+ application it is applied to. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On 6/19/07, Morten Welinder [EMAIL PROTECTED] wrote: In light of bug 438456, is there (or should there be) a way to blacklist a certain theme engine for a certain version range? Bug 438456 causes memory corruption in any gtk+ application it is applied to. I don't see how this is different from any other memory corrupting bug in, say, a library. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
I don't see how this is different from any other memory corrupting bug in, say, a library. From a technical standpoint it is not. However, a theme is a library that is loaded into your application by the end-user. Even if he is not particularly aware of doing so. 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. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
