Blue scary screen

Hi,

I hope you will not hate me for this, but I want to point to


The blue screen which appears when selecting folders shows up on
whenever I switch to another folder. When I'm home or at work does not
make a difference, it is on every single change. I can not start to
explain how irritating this behaviour is.

I'm not sure how this has improved usability in any way, but discussing
that will not be very productive. I'ld like to know if attached patch is
acceptable. If not, I'll close the br and start to compile kmail
manually with a similar patch, because I really would like to use KMail
again.

Tom
Please cc me when replying.

Index: kmmainwidget.cpp

kmmainwidget.cpp (revision 446120)
kmmainwidget.cpp (working copy)
@@ -1787,10 +1787,10 @@
mForceJumpToUnread = forceJumpToUnread;

// Set a timer to show a splash screen if fetching folder contents
- // takes more than a second
+ // takes more than 10 seconds
mShowBusySplashTimer = new QTimer( this );
connect( mShowBusySplashTimer, SIGNAL( timeout() ), this, SLT( slotShowBusySplash() ) );
- mShowBusySplashTimer->start( 1000, true );
+ mShowBusySplashTimer->start( 10000, true );
return;
} else {
// the folder is complete now - so go ahead


KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Wednesday 14 December 2005 23:52, Tom Albers wrote:
The blue screen which appears when selecting folders shows up on
whenever I switch to another folder. When I'm home or at work does not
make a difference, it is on every single change. I can not start to
explain how irritating this behaviour is.

I added this feature in Achtmaal after some talk with Ingo and Thomas, and for
me it has always worked as intended: it only shows up if fetching mail from
an IMAP folder takes more than a second. Admittedly, for t < splashDelay + 1
you would see the splash itself for less than a second. There is no easy way
too avoid that, apart from artificially delaying the hiding of the splash so
it has been visible at least a second.

It might not be the perfect solution to handle the problem of communicating
status to the user, but it was by *far* the easiest one to implement. I do
have an idea that might work better, but it will require quite a lot of code,
so it's somewhat unlikely it will ever see the light of day.

I'm not sure how this has improved usability in any way, but discussing
that will not be very productive. I'ld like to know if attached patch is
acceptable.

I'd say it's not. 1 second is already quite a lot for user feedback, in
general GUIs should respond even sooner, but since there's the progress
thingy in the status bar that's acceptable enough. Plus, raising it to any
arbitrary amount will not solve the fundamental problem that if the operation
is finished shortly after it will appear to be flicker.

There is btw a true bug in the code somewhere that wasn't there in Achtmaal.
I've been using a KMail snapshot from back then for months (!) without any
problems, but since upgrading to 3.5 branch I occasionally hit a race
condition where the splash appears but doesn't hide anymore. The trigger
seems to be switching folders when the splash is visible but about to hide,
but I haven't investigated yet. As I said, that wasn't in the original
codebase, something must have changed elsewhere.

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Hi Ingo,

donderdag 15 december 2005 00:32, schreef u:
Wednesday 14 December 2005 23:52, Tom Albers wrote:
Hi,
>
I hope you will not hate me for this, but I want to point to

>
The blue screen which appears when selecting folders shows up on
whenever I switch to another folder. When I'm home or at work does
not make a difference, it is on every single change. I can not start
to explain how irritating this behaviour is.
>
I'm not sure how this has improved usability in any way, but
discussing that will not be very productive.
>
If (seemingly) nothing happens after the user selected a folder he'll
wonder whether he did something wrong. The progress screen shows the
user that KMail is doing something. Whether a 1 second timeout is too
short or not is of course debatable.

What I do not understand is why there are four ways to tell the user what is
going on:
1) status bar
2) progress bar in the status bar
3) the progress bar in the popup as shown when forwarding a message which is
not completely retrieved yet
4) the blue scary screen

of the objections is that 'we' are now learning the user not to look at 1)
or 2) when something takes longer then expected. I hope it does not set an
example for everything that lasts a bit longer.

I'ld like to know if
attached patch is acceptable. If not, I'll close the br and start to
compile kmail manually with a similar patch, because I really would
like to use KMail again.
>
Sorry, but a 10 second timeout is not acceptable. If you want to invest
a little bit more time on this then you can make the timeout
configurable

Thanks for the hints, attached is the patch based on that. Do I need to take
care of trunk or can someone forward port it? Can I document the hidden
setting somewhere (wasnt there a wiki page for that)?

Tom
Please cc me on replies


KMail developers mailing list
KMail-devel (AT) kde (DOT) org

donderdag 15 december 2005 23:03, schreef Ingo K:
Thursday 15 December 2005 18:29, Tom Albers wrote:
donderdag 15 december 2005 00:32, schreef u:
Wednesday 14 December 2005 23:52, Tom Albers wrote:
I'm not sure how this has improved usability in any way, but
discussing that will not be very productive.
>
If (seemingly) nothing happens after the user selected a folder
he'll wonder whether he did something wrong. The progress screen
shows the user that KMail is doing something. Whether a 1 second
timeout is too short or not is of course debatable.
>
What I do not understand is why there are four ways to tell the user
what is going on:
1) status bar
2) progress bar in the status bar
3) the progress bar in the popup as shown when forwarding a message
which is not completely retrieved yet
4) the blue scary screen
>
of the objections is that 'we' are now learning the user not to
look at 1) or 2) when something takes longer then expected. I hope it
does not set an example for everything that lasts a bit longer.
>
If the usability people think it makes sense then who am I to argue with
them?

You are a user as well.

Anyway, I think it would probably be better to show the "blue
scary screen" only instead of the folder list and leave the message
preview pane empty.
>
I'ld like to know if
attached patch is acceptable. If not, I'll close the br and start
to compile kmail manually with a similar patch, because I really
would like to use KMail again.
>
Sorry, but a 10 second timeout is not acceptable. If you want to
invest a little bit more time on this then you can make the timeout
configurable
>
Thanks for the hints, attached is the patch based on that. Do I need
to take care of trunk or can someone forward port it? Can I document
the hidden setting somewhere (wasnt there a wiki page for that)?
>
Looks good, but I think you should add this option to the General group
instead of the Internal group. The Internal group is only meant for
settings no user should ever change.

, moved and committed.

I suppose you have tested that it
works as expected.

Testing took the most time, as I had to build kdepim for it and I had to read
the KConfigXT manual, but that was on my list anyhow.

I'll port it to trunk.

Thanks for helping to find a solution. I'm a happy user again.

Toma


KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Thursday 15 December 2005 23:03, Ingo K¶cker wrote:
If the usability people think it makes sense then who am I to argue with
them? Anyway, I think it would probably be better to show the "blue
scary screen" only instead of the folder list and leave the message
preview pane empty.

If that were possible without intrusive changes in the existing code I would
have done it like that back in May. I use the current approach because it
maximally reuses existing code.

But if you thing you can pull it off I'm all for it :)

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Resend with Tom on CC

Thursday 15 December 2005 23:03, Ingo K¶cker wrote:
If the usability people think it makes sense then who am I to argue with
them? Anyway, I think it would probably be better to show the "blue
scary screen" only instead of the folder list and leave the message
preview pane empty.

If that were possible without intrusive changes in the existing code I would
have done it like that back in May. I use the current approach because it
maximally reuses existing code.

But if you thing you can pull it off I'm all for it :)

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Thursday 15 December 2005 18:42, Martijn Klingens wrote:
Wednesday 14 December 2005 23:52, Tom Albers wrote:
The blue screen which appears when selecting folders shows up on
whenever I switch to another folder. When I'm home or at work
does not make a difference, it is on every single change. I can
not start to explain how irritating this behaviour is.
>
I added this feature in Achtmaal after some talk with Ingo and
Thomas, and for me it has always worked as intended: it only shows
up if fetching mail from an IMAP folder takes more than a second.
Admittedly, for t < splashDelay + 1 you would see the splash itself
for less than a second. There is no easy way too avoid that, apart
from artificially delaying the hiding of the splash so it has been
visible at least a second.
>
It might not be the perfect solution to handle the problem of
communicating status to the user, but it was by *far* the easiest
one to implement. I do have an idea that might work better, but it
will require quite a lot of code, so it's somewhat unlikely it will
ever see the light of day.
>
I'm not sure how this has improved usability in any way, but
discussing that will not be very productive. I'ld like to know if
attached patch is acceptable.
>
I'd say it's not. 1 second is already quite a lot for user
feedback, in general GUIs should respond even sooner, but since
there's the progress thingy in the status bar that's acceptable
enough. Plus, raising it to any arbitrary amount will not solve the
fundamental problem that if the operation is finished shortly after
it will appear to be flicker.
>
There is btw a true bug in the code somewhere that wasn't there in
Achtmaal. I've been using a KMail snapshot from back then for
months (!) without any problems, but since upgrading to 3.5 branch
I occasionally hit a race condition where the splash appears but
doesn't hide anymore. The trigger seems to be switching folders
when the splash is visible but about to hide, but I haven't
investigated yet. As I said, that wasn't in the original codebase,
something must have changed elsewhere.

I'm seeing this occassionally in a check out from late August. So it
may have been around for awhile. It does feel like a race condition.

Switching to another folder and back seems to be away to work around
the problem.

Don Sanders.

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Friday 16 December 2005 02:38, Don Sanders wrote:
Switching to another folder and back seems to be away to work around
the problem.

if that switch takes more than a second, because otherwise the splash
will not be shown and thus not hidden either.

The "sure" way to solve it is to go to "Local Folders", which displays KMail's
splash. When moving away from there the problem is by definition gone.

But instead of workarounds I'd much rather not see the problem in the first
place :/

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Friday 16 December 2005 19:18, Martijn Klingens wrote:
Friday 16 December 2005 02:38, Don Sanders wrote:
Switching to another folder and back seems to be away to work
around the problem.
>
if that switch takes more than a second, because otherwise the
splash will not be shown and thus not hidden either.
>
The "sure" way to solve it is to go to "Local Folders", which
displays KMail's splash. When moving away from there the problem is
by definition gone.
>
But instead of workarounds I'd much rather not see the problem in
the first place :/

Sure.

Actually I experience several other online IMAP issues in addition to
this. Moving a large number of messages (10,000 say) from IMAP to
local slows KMail down and eventually freezes it. Sometimes when new
mail is collected while an IMAP folder is shown all the fields in the
list of message headers go blank, except the threading hierarchy
remains. Also switching folders and reading messages while moving
messages out of an IMAP can cause KMail to crash.

Perhaps it's just the particular check out I have it is quite stale
now. I wanted to keep the base I was working with stable while
looking into action scheduler issues.

Don Sanders.

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Monday 19 December 2005 02:46, Don Sanders wrote:
Actually I experience several other online IMAP issues in addition to
this. Moving a large number of messages (10,000 say) from IMAP to
local slows KMail down and eventually freezes it. Sometimes when new
mail is collected while an IMAP folder is shown all the fields in the
list of message headers go blank, except the threading hierarchy
remains. Also switching folders and reading messages while moving
messages out of an IMAP can cause KMail to crash.

I noticed the latter two too. I don't move large amounts of mail usually, but
I suspect I'd be able to have that too, seems like we've got a largely
similar setup.

Those problems have nothing to do with the splash screen though, so I'd say
you're now hijacking the thread here :)

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Monday 19 December 2005 21:19, Ingo K¶cker wrote:
Sometimes when new
mail is collected while an IMAP folder is shown all the fields in the
list of message headers go blank, except the threading hierarchy
remains.
>
I just saw the same problem (I don't remember seeing it before), but I
was fetching mail from the local mail spool into a local folder. So
this seems to be a general problem which probably just occurs more
often with IMAP(?).

I think it occurs if KMail detects new mail while I'm switching focus to
another mail by keyboard or mouse at the same time. The new mail updates the
listview by adding nodes, the mail switch updates the current item in the LV.

It's guesswork though based on the ~5 times I've seen it the past couple of
days. Switching to another folder and back is a workaround, so it's certainly
not affecting KMail's internal data structures. (Well, it might, didn't
Valgrind, but seems unlikely.)

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Tuesday 20 December 2005 07:20, Martijn Klingens wrote:
Monday 19 December 2005 21:19, Ingo K¶cker wrote:
Sometimes when new
mail is collected while an IMAP folder is shown all the fields
in the list of message headers go blank, except the threading
hierarchy remains.
>
I just saw the same problem (I don't remember seeing it before),
but I was fetching mail from the local mail spool into a local
folder. So this seems to be a general problem which probably just
occurs more often with IMAP(?).

That's interesting.

I've just updated my filters from mainly filtering IMAP mail into IMAP
folders to filtering IMAP mail into local folders. Now that I'm back
to mainly using local folders I'll keep an eye out to see if I also
observer the problem for local folders.

At the moment I can't think of what can be causing it.

I think it occurs if KMail detects new mail while I'm switching
focus to another mail by keyboard or mouse at the same time. The
new mail updates the listview by adding nodes, the mail switch
updates the current item in the LV.

I get a similar impression.

It's guesswork though based on the ~5 times I've seen it the past
couple of days. Switching to another folder and back is a
workaround, so it's certainly not affecting KMail's internal data
structures. (Well, it might, didn't Valgrind, but seems unlikely.)

Maybe something that changed in kmheaders introduced it. I guess it is
a regression since KDE 3.4?

Don Sanders.

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Wednesday 21 December 2005 02:20, Don Sanders wrote:
It's guesswork though based on the ~5 times I've seen it the past
couple of days. Switching to another folder and back is a
workaround, so it's certainly not affecting KMail's internal data
structures. (Well, it might, didn't Valgrind, but seems unlikely.)
>
Maybe something that changed in kmheaders introduced it. I guess it is
a regression since KDE 3.4?

Yes. My previous (early June) checkout didn't have the problem, so the change
has happened since.

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Wednesday 21 December 2005 18:53, Martijn Klingens wrote:
Wednesday 21 December 2005 02:20, Don Sanders wrote:
It's guesswork though based on the ~5 times I've seen it the
past couple of days. Switching to another folder and back is a
workaround, so it's certainly not affecting KMail's internal
data structures. (Well, it might, didn't Valgrind, but seems
unlikely.)
>
Maybe something that changed in kmheaders introduced it. I guess
it is a regression since KDE 3.4?
>
Yes. My previous (early June) checkout didn't have the problem, so
the change has happened since.

I've seen it on a checkout form late August. So I guess the
problematic commit occurred between June and August (inclusive).

I'm guessing the commit was to kmheaders, but maybe something else. I
wonder if completely closing the KMFolder currently shown by
kmheaders could cause it. Maybe I'll have time to attach gdb to the
kmail process and snoop around next time it happens here.

Don Sanders.

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Monday 19 December 2005 22:20, Martijn Klingens wrote:
Monday 19 December 2005 21:19, Ingo K¶cker wrote:
Sometimes when new
mail is collected while an IMAP folder is shown all the fields in the
list of message headers go blank, except the threading hierarchy
remains.
>
I just saw the same problem (I don't remember seeing it before), but I
was fetching mail from the local mail spool into a local folder. So
this seems to be a general problem which probably just occurs more
often with IMAP(?).
>
I think it occurs if KMail detects new mail while I'm switching focus to
another mail by keyboard or mouse at the same time. The new mail updates
the listview by adding nodes, the mail switch updates the current item in
the LV.

I just had it again, but as I was not using the mouse this time I saw some
possibly interesting other effects.

I was going over the last couple of mails in kde-commits (an online IMAP
folder) when the new mail check kicked in. The listview flashed due to a
repaint ans changed all red-coloured (new) mails to blue (unread). This is
rather annoying in and of itself if it's the folder I'm actively working at,
since the repaint collapsed read threads as well. Whether related or not to
the real problem I don't know though.

Anyway, the next that happened was that I was about to go to the next mail and
select it with shift-right arrow, and this key had no effect anymore. None of
the navigation keys worked, KMail really thought the folder was empty.
However, the GUI still showed the mails and a scrollbar. Using the scroll
wheel from the mouse triggered the painting oddity that we talked about
before, now I got the white listview entries.

Switching to another folder and back restored KMail to normal.

Looks like KMail can 'forget' about all mails in the currently visible folder,
but (fortunately) in a non-persistant, non-data corrupting way. And along the
way it doesn't even update the listview.

Hope this helps.

For now, X-mas time. Merry Christmas to everyone on this list too!

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org

Sunday 25 December 2005 12:57, Martijn Klingens wrote:
Monday 19 December 2005 22:20, Martijn Klingens wrote:
Monday 19 December 2005 21:19, Ingo K¶cker wrote:
Sometimes when new
mail is collected while an IMAP folder is shown all the fields in the
list of message headers go blank, except the threading hierarchy
remains.
>
I just saw the same problem (I don't remember seeing it before), but I
was fetching mail from the local mail spool into a local folder. So
this seems to be a general problem which probably just occurs more
often with IMAP(?).
>
I think it occurs if KMail detects new mail while I'm switching focus to
another mail by keyboard or mouse at the same time. The new mail updates
the listview by adding nodes, the mail switch updates the current item in
the LV.
>
I just had it again, but as I was not using the mouse this time I saw some
possibly interesting other effects.

Another *very* interesting one: I just had this on KDE 3.4 (!!!). Using the
3.4.1 level "a" (Kontact 1.1.1) rpms from suse for 9.2 at work, and I had the
problem.

The use case this time was different. Again it happened during the check for
new mail, but this time there wasn't actually any new mail to report. And I
wasn't browsing mail, but instead hit 'send' on a reply.

Perhaps the cause is not so much incoming mail, but instead the change of
status bits (read/unread, or in this case 'replied') while the check for new
mail is going on? The IMAP connection goes all the way from work to home, so
it has been slower and had more latency than when I'm at home. This might be
important, since we're quite likely talking about an obscure race condition
here.

--
Martijn

KMail developers mailing list
KMail-devel (AT) kde (DOT) org