Re: Bugzilla: Reducing bugspam and finding patches
Hey, Nice work :-) On Wed, 2005-06-15 at 00:39 +0200, Olav Vitters wrote: 3. Already fixed (duplicate) Some crashers have been fixed a long time ago, but they still receive daily bugreports. These bugreports can now be rejected automatically. For this the first 5 functions of the stacktrace are used, coupled with the GNOME version (to prevent regressions being rejected). This one worries me a little - e.g. look at one of the panel crashers: 150809 /GNOME2\.8\./ gtk_widget_set_sensitive g_cclosure_marshal_VOID__POINTER g_closure_invoke g_signal_has_handler_pending g_signal_emit_valist gnome-panel Its certainly conceivable that we introduce some new crasher with that signature. I guess, though, that since we're only matching against GNOME 2.8 bugs, its less of a worry. I wonder would it be better to leave these bug reports through and automatically mark them as duplicates ... that way its always in the database for someone to find later. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
On Wed, 2005-06-15 at 10:09 +0800, Davyd Madeley wrote: On Tue, 2005-06-14 at 11:13 +1000, Nigel Tao wrote: ABOUT: This is a small Gnome applet that is like Google's Deskbar, but it 1) runs on Linux, and 2) can use search engines other than Google. This is pretty nifty. Thanks, mate. Admittedly, I use my applet less often these days, since Epiphany can Google directly from the location bar. And as a full-blown application, Epiphany gets a global keyboard shortcut, which (AFAICT) an applet cannot. Kudos to the Ephy guys - it rocks my world! Nigel. Tip #1: Stick the Deskbar Applet in the bottom-left corner (and kick out the show-desktop button) for maximum Fitts goodness. I've been so much less productive when looking up anything and everything in the Wikipedia is just a slam-the-mouse-in-the-corner away. :) Tip #2: I just came across www.yubnub.org a couple of days ago. Add this engine to the Deskbar Applet: u Yubnub http://www.yubnub.org/parser/parse?command=%% ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla: Reducing bugspam and finding patches
3. Already fixed (duplicate) Some crashers have been fixed a long time ago, but they still receive daily bugreports. These bugreports can now be rejected automatically. For this the first 5 functions of the stacktrace are used, coupled with the GNOME version (to prevent regressions being rejected). This one worries me a little - e.g. look at one of the panel crashers: 150809 /GNOME2\.8\./ gtk_widget_set_sensitive g_cclosure_marshal_VOID__POINTER g_closure_invoke g_signal_has_handler_pending g_signal_emit_valist gnome-panel ... Cheers, Mark. I suspect this heuristic would fail for a number of at-spi/accessibility bugs as well, since the stack frames (especially in non-debug builds) can look the same for quite different root causes, if things go haywire in a CORBA call. It's a great idea, and I am all for it, but I agree with Mark that 5 functions of a stack trace are not conclusive. Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:33 -0400, Owen Taylor wrote: On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote: Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? The way glitz integrates in is on the server side: GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL This will give the same basic performance benefits as having Cairo use glitz directly, but with many less complications. Currently, we don't foresee having GTK+ render via glitz as a very interesting way to go for the desktop. Note that the performance slowdowns people have been seeing for GtkTextView likely have not much to do with rendering and everything to do with text measurement. You'll have to excude me for not having followed much cairo/X work for a while, but does that ' --- RENDER ---' imply that cairo is rendering lots of traps using the RENDER extension? Thanks, Rob Taylor ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla: Reducing bugspam and finding patches
On Wed, 2005-06-15 at 11:15 +0100, Bill Haneman wrote: 3. Already fixed (duplicate) Some crashers have been fixed a long time ago, but they still receive daily bugreports. These bugreports can now be rejected automatically. For this the first 5 functions of the stacktrace are used, coupled with the GNOME version (to prevent regressions being rejected). This one worries me a little - e.g. look at one of the panel crashers: 150809 /GNOME2\.8\./ gtk_widget_set_sensitive g_cclosure_marshal_VOID__POINTER g_closure_invoke g_signal_has_handler_pending g_signal_emit_valist gnome-panel ... Cheers, Mark. I suspect this heuristic would fail for a number of at-spi/accessibility bugs as well, since the stack frames (especially in non-debug builds) can look the same for quite different root causes, if things go haywire in a CORBA call. Well, in that case we just wouldn't use this thing for at-spi bugs - i.e. not add at-spi bugs to the configuration. That brings up another point actually - it might be a good idea for bugsquad people to consult with the maintainer before adding bugs to the configuration. Maintainers should be able to sport stack traces which could match other bugs. All I'm saying really is that there's a tiny chance of this thing going wrong for a certain bug and if it rejects bugs rather than allowing them into the database and marking them as a duplicate, we'll not have a chance to ever actually see it going wrong. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
On 15 Jun 2005, at 03:09, Davyd Madeley wrote: On Tue, 2005-06-14 at 11:13 +1000, Nigel Tao wrote: ABOUT: This is a small Gnome applet that is like Google's Deskbar, but it 1) runs on Linux, and 2) can use search engines other than Google. This is pretty nifty. Isn't this pretty much what the webeyes applet in GNOME CVS did already? Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
* Jun 15 10:22 Nigel Tao [EMAIL PROTECTED]: And as a full-blown application, Epiphany gets a global keyboard shortcut, which (AFAICT) an applet cannot. I think it can, IIRC tomboy does this. -- Johan Svedberg, [EMAIL PROTECTED], http://johan.svedberg.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
On Wed, 2005-06-15 at 15:58 +0200, Johan Svedberg wrote: * Jun 15 10:22 Nigel Tao [EMAIL PROTECTED]: And as a full-blown application, Epiphany gets a global keyboard shortcut, which (AFAICT) an applet cannot. I think it can, IIRC tomboy does this. Off the top of my head (I currently don't have tomboy installed, so I might be just plain wrong), tomboy has a shortcut to open a new window (i.e., a new note), but I want a shortcut to shift focus to an existing window (or, more precisely, a GtkEntry inside an applet inside a panel). This may or may not be an important difference. I tried to code something up a number of months back, pre-2.10, but got stuck. It might be easier now, with the new request_focus API. One more for the TODO list, I guess. :) Also, possibly off-topic, tomboy's keybinding code is some Xlib magic, written in C (as opposed to the rest of Tomboy, in C#), rather than a GNOME or GTK API. If I wanted to re-use the code, but not just blind copy-and-paste, what's the process for bumping such a thing up into GNOME, and where should it live? libegg? Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla: Reducing bugspam and finding patches
On Wed, 2005-06-15 at 17:25 +0200, Olav Vitters wrote: In the near future I want to make this for open bugs as well. For those I haven't decided if either a comment should be added to the original bug, or to create a new bug and dupe it right away. Please create a new bug and dupe it. The descriptions of the dups are sometimes very important in finding out where the problem lies. While the individual descriptions might not be so informative, when reading enough of them, most of the time a pattern emerges (It always happens when a window is closed after a transfer). I wouldn't have been able to fix some crashes without that information. Anyway, autoduping rocks - Thanks for making it happen. Martin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla: Reducing bugspam and finding patches
On Wed, Jun 15, 2005 at 11:06:17AM -0700, Alex Graveley wrote: If this happens, just please make sure to handle mono's gdb stacktraces specially, which all look like this... Do you mean rejection of bugs based on the stacktrace? It already works. No bugs rejected yet though. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) That is of course ignored. PS (in general): I had a question who could add/remove stacktraces to the file. Of course every maintainer can do this. In the original message I did refer a lot to Bugsquad. I did that so there would be an additional check to ensure the stacktraces are unique. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
