Bug 116773

I agree. It's more irritating than informational.

This screen was added because of feedback from the usability team if I can remember correctly. It should help the user to know what is going on. So here we have to opposed opinions.

My guess is that the usability team is not using online imap. I could not stand it anymore. The delay for showing that screen should be set at 10 seconds, not at 5 miliseconds or something. There is a progress bar, if a user wants to know what is going on before the screen is shown, it can click on the arrow up to see it.

It would be nice if I could use KMail again in 3.5.1. Does anyone mind if I increase the timeout in SVN?

SVN commit 488792 by toma:

Make the time before showing the splash when opening a mailfolder on imap configurable in the ini. 
BUG: 116773 


 M  +3 -0      kmail.kcfg  
 M  +2 -2      kmmainwidget.cpp  


--- branches/KDE/3.5/kdepim/kmail/kmail.kcfg #488791:488792
@@ -109,6 +109,9 @@
         <default>0</default>
 	<min>0</min>
       </entry>
+      <entry name="FolderLoadingTimeout" type="Int" hidden="true">
+         <default>1000</default>
+      </entry>
    
 
     </group>
--- branches/KDE/3.5/kdepim/kmail/kmmainwidget.cpp #488791:488792
@@ -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 the amount of seconds configured in the kmailrc (default 1000 msec)
       mShowBusySplashTimer = new QTimer( this );
       connect( mShowBusySplashTimer, SIGNAL( timeout() ), this, SLOT( slotShowBusySplash() ) );
-      mShowBusySplashTimer->start( 1000, true );
+      mShowBusySplashTimer->start( GlobalSettings::self()->folderLoadingTimeout(), true );
       return;
     } else {
       // the folder is complete now - so go ahead

May I suggest that the usability team be sacked and this godawful idea be backed out completely? :(

For KDE 3.5.1 you can edit your kmailrc when kmail is closed (make a backup first) and add under the section [general] a new line containing:
FolderLoadingTimeout=10000

That gives the blue screen after 10 seconds, which is fine, because then you know something special is happening.

Can this please be made configurable in the GUI?  Even now that I know how to set the timeout in kmailrc, I have to plow through ~/.kde/share/...... on every machine on which I use KMail.  Yes, it is probably a one-time thing (until the usability team has another great idea), but it is not just _me_ who has to do it, and many people who are annoyed by this feature won't find this bug report with the secret config option.

I'd suggest making the screen look less ugly on non-standard color-schemes and remove that timeout-option altogether.
The progressbar inside the statusbar indeed can be overlooked easily so the screen in general makes sense (no window contents at all don't make more sense, do they?). Maybe showing a centered progressbar or something.

Stefan Gehn wrote:
> (no window contents at all don't make more sense, do they?)

It's a matter of taste, I guess.  I prefer an empty window and a subtle progress bar in a lower corner of the screen to an HTML-formatted, colored full-window message.  (And it's less resource hungry, too.)

Perhaps take a look at what Windows does when populating an Explorer (not IE) window: it displays a folder symbol and a waving flashlight in the center of the window.  Something like that might be unobtrusive enough to suit everybody.  Otherwise, please give users an easy way to turn it off!

It would be nice if one could see the messages that are there while kmail is checking for new mail in the background.

I get frustrated waiting for 10+ seconds before I can do anything at all when I may simply want to check at existing email message.

Hi, just wondering why this is RESOLVED FIXED. It seems to me that the guy was asking for a way to turn off the loading screen. Has it been added yet?

No, there is no easy way to turn it off.  You have to edit the KMail config file manually.

This seems to be KDE's usual way of dealing with bug reports about UI changes.  Nobody cares if whatever UI changes they come up with isn't liked by the users.
Cf. <http://www.kdedevelopers.org/node/3883>.  Alright, enough ranting.