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

[Emmanuel <e allaud wanadoo fr>]

On 2001.12.09 06:04 Peter Bloomfield wrote:
> 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=<F630iUnz4wJa2s1PV9y000128a2@hotmail.com>
>> 
>> (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 
> machine?
> 
No not at all. Local X-server. I have just remarked that to get the borked 
line, I had to move around the elevator cursor of the messages index a bit 
quickly, during several seconds. In fact now that you talked about bad 
behaviours when too many events occured, I think that when I did that it 
just flooded gtk with event and leaded to this incoherency between the 
clist and the ctree. Hmm, I think you also have, after having moved around 
the elevator I had to expand a thread to hide the last line (because of 
the thread expansion), then when I scroll down to the last line it is 
borked and presents the incoherency. Now I'm not even sure that you need 
to expand/collapse a thread to trigger the bug. I looked to that later.
But anyway we should perhaps forward this to gtk team, I'm now convinced 
that this is a gtk bug, not a balsa one (I think I'll try to make an 
example program to see). And why do you talk of getting rid of gtkctree, 
what are the allternatives ?
Bye
Manu
Bye
Manu