Re: Balsa's thread handling very buggy.



On 07/14/2003, Andrew Lau wrote:
> Hey everyone,
> 
> After going through the Bugzilla and Debian bug lists for Balsa, I've
> noticed that we have some serious stability problems regarding
> operations on threads.
> 
> * Reports of operations causing a hang:
> Move:	http://bugzilla.gnome.org/show_bug.cgi?id=117323
> Delete:	http://bugzilla.gnome.org/show_bug.cgi?id=112280
> 	http://bugzilla.gnome.org/show_bug.cgi?id=112839
> 
> * Report of operations affecting only the first item in thread:
> Move:	http://bugzilla.gnome.org/show_bug.cgi?id=102143
> Delete:	http://bugzilla.gnome.org/show_bug.cgi?id=102146
> Copy:	No report yet, but I can reproduce it
> 
> I've seen all of these bugs before, and my guess would be that Balsa  
> drag/drop bugs depend upon the version of libgtk2.0-0 installed. On  
> the Debian GNU/Linux unstable system I use build/test Balsa, and from  
> my memory, operations on collapsed threads with libgtk2-0.0 2.2.1-6  
> or earlier would hang Balsa.

That may have been the cancel-arrow-animation bug; if it was, it's been  
fixed, and I don't see any way to work around it for those with older  
libs.

> If 2.2.2-1 or later is installed as I have now, then the operation
> performed (copy, move, or delete) will only affect the first message  
> in the thread.

That's by design.  The handling of threads was discussed on the Balsa  
list a couple of years ago (see in particular  
http://mail.gnome.org/archives/balsa-list/2001-October/msg00552.html )  
and the consensus was that a message operation is always a message  
operation, not a thread operation, regardless of whether the thread is  
expanded or collapsed.

Reversing that convention is feasible, iirc, but represents a major  
change in the model--I believe we'd want to see some discussion on the  
list before making a change.

> http://bugzilla.gnome.org/show_bug.cgi?id=114460
> 
> So what can we do about these bugs? Are we looking at a rewrite?
> 
> Yours sincerely,
> Andrew "Netsnipe" Lau
> 
> PS: How come there are no gray lines linking threads together? In  
> really long threads, it's hard to see which message is a parent or  
> reply of another. It's a lot easier to follow lines in my opinion  
> (see mutt). Is this a limitation of GTK+2's GtkTreeView?

Lines are supported by GtkTreeView--that may be something you can  
specify in ~/.gtkrc, but I don't know for sure, being totally gtkrc- 
illiterate.

Peter



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]