Re: [Evolution] Weird focus behavior when deleting messages.



On 06 Apr 2001 09:06:34 +1000, Rodd Clarkson wrote:
If I have Hide Deleted Messages inactive, then deleting messages works
like you would expect.  You delete a message (it gets marked as deleted)
and the focus moves to the next (not deleted) message.

However, if you active Hide Deleted Messages, when you delete a message,
the messages disappears (as expected), but the focus goes all weird.
Often it opens the message two down from the one you just deleted, and
no message actually gets the focus.  Also, messages that are part of a
message thread seem to get scattered to the four winds, which actually
makes sense but is somewhat disconcerting (although I've got no idea how
is best to handle this).


I dunon maybe the weird behaviour is etree, i can't see why the code is
selecting like two-down or whatever.  I've seen the focus problem and
Clahey reckons he's fixed it, but i dunno.

The tree view-sorted problem is incredibly difficult to fix.  Either we
have to add more to the laready overly bloated and complex etree (and
some of that even might not be easy to add), or we have to do the
sorting ourselves, which kind of throws away all the work in the
aforementioned overly bloated and complex etree.

Given that the focus works properly when you aren't hiding deleted
messages, but fails when you are I have a theory on why it goes down
two.

When you don't hide deleted messages, you delete a message and the focus
moves down one.

However, when you are hiding deleted messages, when you hit delete, the
message disappears affectively handing focus to the message below, and
then moves the focus down one, meaning that the message two down is
opened (as it happens so fast).

Why the message isn't actively selected is something I have no theory
on.

I can't read the code to prove this, it's just what my gut is telling
me.


Well the thing is, we actively select the original back again.  i.e. we
save the id of the message we want to reselect, then clear the whole
list, rebuild it then find it in our tree again (by id), and THEN select
that node in the tree.  We're not doing anything like "removing 3 rows,
so select the third row from where we are" at all (unless etree is which
i wouldn't be suprrised).  Most everyone on evolution is at GUADEC this
week, so might have to wait till they get to their mail, etc.

So either etree is tryign to be smart about it, and doing a lousy job,
or there is something else very weird going on.






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