Re: [BUG] : investigation of the "last line" weirdness
- From: Emmanuel <e allaud wanadoo fr>
- To: balsa-list gnome org
- Subject: Re: [BUG] : investigation of the "last line" weirdness
- Date: Sun, 9 Dec 2001 20:08:25 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]