Re: [BUG] : investigation of the "last line" weirdness

On 2001.12.07 12:12 Emmanuel wrote:
> 	Hi all,
> I'm investigating the last line bug : now I'm convinced that we 
> should "pass the baby" to gtk team. It's definitely something wrong 
> with gtkclist/ctree. I have put 2 g_print, one in the 
> button_event_press_cb that is responsible to handle click on the 
> message index (line 1277, src/balsa-index.c):
>     if (on_message) {
> 	message = (LibBalsaMessage*)gtk_clist_get_row_data(clist, row);
> 	if (message) {
> +	    g_print("row=%d; message=%p; message 
> id=%s\n",row,message,message->message_id);
> and in the select_message (callback for "tree-select-row" signal of 
> the messages index tree), line 1334, src/balsa-index.c :
>     message = 	LIBBALSA_MESSAGE(gtk_ctree_node_get_row_data 
> (GTK_CTREE(widget), row));
> +    g_print("Select : row=%d; message=%p; message id=%s\n",
> +	    gtk_clist_find_row_from_data(GTK_CLIST(widget),message),
> +	    message,message->message_id);
> So when you select a message in the index you have two lines printed 
> on your console. But whenever you manage to have a bad last line (in 
> general I just have to quickly scroll the index of a big mailbox), 
> you click on the last line and you get things like
> row=3118; message=0x92b82f0; message id=<20011205173607.A571@a800>
> Select : row=3118; message=0x92b9190; message 
> id=<>
> (First line is given by the button_event_press_cb, second by 
> select_message)
> That is both functions agree on the line that has been selected but 
> the associated data is different depending on the method you have 
> chosen to retrieve it! Indeed in the select_message we retrieve the 
> associated message with gtk_ctree_node_get_row_data that gives the 
> good result, but in button_event_press_cb we use 
> gtk_clist_get_row_data that gives an erroneous result (and you can 
> check that : the panel displays the selected message, whereas if you 
> double-click on the message index you have another message displayed 
> in the window!). That is a bit crazy, I don't really explain why this 
> happens, but it happens :)
> So either we make a mistake with the different signals or something 
> is wrong in gtkctree.
> Comments.
> Bye
> Manu

Hi Manu!

Good work!  This looks like one more reason for moving on from GtkCTree 
as soon as possible!

One way that what you're seeing might possibly arise is this: the 
GTK_CLIST of a GtkCTree shows only the viewable nodes, so the row 
number of a message changes when any thread above it is expanded or 
collapsed. Perhaps the updating of the CList structure is interrupted 
by another event, and never gets completed.

I haven't been able to reproduce this problem, even after loading up a 
mailbox with 3,000+ messages. However, I haven't tried using that 
mailbox over an X-connection; the delays involved in using Balsa 
remotely have shown up other places where there were timing issues, so 
I'll have to try this one too. Do you, by chance, use Balsa on a remote 


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