Re: 1.4 Issues

[Lynn Kerby <lfk kerbit net>]

On 2003.04.08 16:47 Melanie wrote:
>Hi,
>
> I was forced to discontinue using Balsa. I am having major problems
>that have forced me to use Evolution for the time being. My problems are
>these:

I feel your pain and have encountered many of the same issues myself....

>Compilation issues:

I just use a tarball version, but I don't think I've got these problems
building from CVS - it has been a while.  I'm on a RH7.3 system that has
been through several upgrade/downgrade cycles for auto* tools in order to
build other projects.

>* Missing pixmaps will cause a segfault. As a person who does not like
>to blindly use 'make install', running Balsa from the src/ directory is
>not possible

I haven't seen this since I've installed a 1.4.x rpm for balsa (though I
use the binary from my patched version)

>Running issues:
>
>* Balsa will segfault intermittently when displaying a message in the
>preview pane. The crash is preceded by numerous gtk warnings and cannot
>be debugged because of stack corruption (no bt possible, unusable  core
>files)

I've seen this a couple of times.  Can't help here.

>* Clicking any link or choosing 'open' from a context menu will hang
>Balsa. It needs a sigterm and all deleted messages, hundreds of them
>sometimes, are back in my inbox when I restart it.
>
>* Twice I have observed a condition where Balsa hangs and also hangs the
>entire X server. No windows are responsive and I have to switch to a
>text console (takes forever) or use a network login from another machine
>to kill Balsa. After Balsa is killed, X recovers. Evolution has also
>shown this behavior once, so the root cause may be some library used by
>both.

I have been trying to track down a bug where balsa 1.4.2 freezes due to
what appears to be a thread that didn't release the GDK threads lock.
It could be related.  Unfortunately, when I built my own libgdk with
'-g' in a few files and modified the locks to support debugging the
problem has vanished.

>Balsa 2 works, but I don't want to use it. It wastes screen space. With
>1.4, I can view my entire mailbox tree without scrolling, with Balsa 2
>it is almost twice as tall and I must scroll to access mailboxes located
>further down the tree. Also, when I resize the columns in the tree so
>that the names are shown entirely and the counts are also visible, the
>remaining horizontal space is not sufficient to display all of a
>properly formatted text message. Using Balsa 2 forces too many usability
>compromises. There seems to be no way to independently control the font
>size used in the tree view, or, if I do change it, the cell height of
>the tree view does not decrease accordingly, all I get is smaller text.

Yes, I found this immediately upon install/test of balsa 2.  As Peter
Bloomfield points out, I have a suggested work-around (see his followup
for the mailing list thread).  I've been completely ignored on the GTK
development list and attempts to send email directly to the author of
the GtkTreeView/GtkCellRenderers have been ignored as well.  As far as
I'm concerned, this is a *major* usability issue with these widgets
and the apparent fact that the space is not themeable or configurable
other than by an application is a BUG.  I have similar issues with the
PageUp/PageDown and scolling windows in GTK (as some may recall).

>Also, though this is really a gtkhtml issue, at least with Balsa 2 I
>have observed that certain spam messages will send gtkhtml into a loop
>that will constantly increase the width of the document. If it is not
>stopped very quickly, it will segfault.

There was change to balsa in the 2.x tree that fixes this problem.  I'm
attaching a backported version (though I don't think there was any change
required) that will a apply to 1.4.2.

-- 
Lynn Kerby <mailto:lfk@kerbit.net>
--- balsa-message.c.orig	2003/02/20 00:30:58
+++ balsa-message.c	2003/02/20 00:31:27
@@ -2853,11 +2853,6 @@
 #ifdef HAVE_GTKHTML
 /* balsa_gtk_html_size_request:
    report the requested size of the HTML widget.
-
-   FIXME: this is not 100% right. The code includes an empirical
-   (hehe) term -1 (marked with EMP) which is NOT the right way to
-   go. The right solution requires some study of size_request signal
-   handling code.  
 */
 static void
 balsa_gtk_html_size_request(GtkWidget * widget,
@@ -2867,11 +2862,8 @@
     g_return_if_fail(GTK_IS_HTML(widget));
     g_return_if_fail(requisition != NULL);
 
-    requisition->width  = (widget->style->klass->xthickness + 1) * 2;
-    requisition->height = (widget->style->klass->ythickness + 1) * 2;
-
-    requisition->width  += GTK_LAYOUT(widget)->hadjustment->upper -1 /*EMP*/;
-    requisition->height += GTK_LAYOUT(widget)->vadjustment->upper -1 /*EMP*/;
+    requisition->width  = GTK_LAYOUT(widget)->hadjustment->upper;
+    requisition->height = GTK_LAYOUT(widget)->vadjustment->upper;
 
 }