Agreed and confirmed.

The selection works fine here but only downwards. It finds the next folder 
that starts with the typed key. Can you confirm this?

It works (sometimes) only downwards and only between sister elements.
It does e.g. not work if I have
1a
aa
bb
cc

1a is selected, I press c -> nothing happens

For me it is complete random what works and what does not.
Try it. Press a key, click with the mouse onto another elemen, press a key ... 
random

Confirmed here. 
more details: 
- it happens not only with "M"move key, but also with "C"opy. 
- the selection works only if the next folder downwards starts with the typed key.
example:
Awhatever
Awhatever2
Awhatever3
Bwhatever

Starting from the first menu, Typing "A" the cursor goes down, typing "B" no, unless the cursor is already on "Awhatever3" entry (the one preceeding "B" folder). It doesn't matter if the next folder is child, on the same level or at upper level of the one pointed by the cursor, only starting letter matters.


Can someone confirm?

I just built and installed 3.4.0 to get fixes for other kmail bugs.  I was very pleased with the new KDE until I ran into this problem.  I can confirm that the bug exists in the 3.4.0 version of KDE (which uses kmail version 1.8)

I have the same problem with the current 3.3 KDE packages from Mandrake (they update it to the branch every now and then or something, and sometimes backport from HEAD).

*** Bug 101896 has been marked as a duplicate of this bug. ***

I can confirm this behavior. First time I noticed it was when I upgraded from kde 3.3.0 to 3.3.2 with suse 9.2. Problem still there after upgrading to 3.4.0. 

I have isolated the problem to qt-3.3.4, at least in my setup (using the fc3 rpms for kde 3.4 from the kde website).  When I found this bug, I reverted to kde 3.3.2 (again using rpms on kde website) but they didn't include qt rpms, so it still had the qt-3.3.4 rpms, and this bug was still present.  So, you get it with kmail 1.7.2 and qt-3.3.4 -- maybe qt changed its keyboard completion behavior?  Probably this accounts for the variability in above reports.

I don't know if you can run kde 3.4 under qt 3.3.3 -- I might try that..

Looking at the qt changes-3.3.4 file, this looks like a possible source of the problem:

QListView
Fixed bad parameter to QListViewItem::text() on key press with
        an unsorted list view.

*** Bug 104697 has been marked as a duplicate of this bug. ***

*** Bug 106258 has been marked as a duplicate of this bug. ***

This is indeed a bug which was introduced in Qt 3.3.4. I've informed Trolltech. The following patch for qlistview.cpp fixes the problem:
--- qlistview.cpp.orig  2005-01-21 18:16:23.000000000 +0100
+++ qlistview.cpp       2005-06-02 01:26:53.000000000 +0200
@@ -5026,6 +5026,7 @@ void QListView::keyPressEvent( QKeyEvent
                QString keyItemKey;
                QString prefix;
                while( keyItem ) {
+                   keyItemKey = QString::null;
                    // Look first in the sort column, then left to right
                    if (d->sortcolumn != Unsorted)
                        keyItemKey = keyItem->text(d->sortcolumn);

Closing as invalid because it's no bug in KMail/KDE.

SVN commit 425432 by burghard:

Use the kfoldertree as parent class for the folder selection dialog.
Therefore we get a correctly sorted column and this works around the qlistview limitation.
I set the folders to be opened according to the foldertree as I think this is more convenient
than opening all folders, especially if you have lots of folders.
CCMAIL:99428@bugs.kde.org


 M  +21 -35    kmfolderseldlg.cpp  
 M  +2 -2      kmfolderseldlg.h  

Is it possible to receive some kind of clarification as to the new behavior ? The reason is that I'm afraid that the described behavior is a regression for my particular usage: 
The reason I use the "move to" dialog is that I don't want to keep my list of folders open (which is quite big and composes a complicated tree) - I usually have either only the inbox visible or only the inbox and the top level folders, and I use "move to" to folders I don't see. Otherwise I'd just drag the email to a visible folder (which I do if the folder is listed in the tree even if I have to scroll a little).

If the "move to" dialog will always show the folder tree as it is shown now in the mail folder view, then its completely useless to me, and it will only be slightly better if I could keyboard-navigate to a folder which is not currently visible in the dialog because its parent folder is closed - something no tree view I'm familiar with can do.

Evolution behaves very similar in respect that whenever a mail box is being opened (which happens after the client starts but also if the mailbox disconnects for some reason) the "move to" dialog starts exactly as the folder view is collapsed (which for me means completely closed) and I have to open everything down to where I want to store the email, something which entails many mouse clicks and is driving me nuts. On the plus side, until the mailbox disconnects, Evolution remembers the open state of the folder tree in the "move to" dialog regardless of the state of folder view, so once I open up all the paths I regularly use, I don't have to do it again, and its keyboard navigation is pretty solid (although predictably does not allow you to navigate to non-visible folders).

The behavior I would expect from the "move to" dialog in kmail, is that it will remember the open state of the folder tree disjointed from the open state of the folder view, and across sessions (so it will no revert back after I close the dialog or after I close kmail) - kind of like kmail's folder view works right now. I would also prefer that the default state would be for "all open", but I understand its probably much less useful to other people and I can live w/o it.

I back up the previous comment - I use the move-to dialogue
with keyboard search to quickly locate folders in my lush tree
without having to navigate through 4-8 layers.  If not all folders
are open, the dialogue will be of little use to me and the single
big reason I prefer kmail over other mail clients will disappear.
If I am not alone in this, I would advocate having a setup option to
keep the open-all behaviour for people like myself.

I'll add another impassioned vote for keeping the old behavior of flat list, or at least a fully open tree view.  This is also one of the main reasons that I use kmail over other clients.  Any update on when a patched version of Qt will be available to restore the old behavior?

I like having the list mirror the folder list, so at least make this an option. The dialog is far to small to click around in trying to find my folders, and I just end up typing the folder names anyhow. It's much faster. My hiearchy is very large and looking through it in the little dialog is nearly impossible with a mouse.

SVN commit 429480 by burghard:

Upon user request: restore the old behaviour to open all folders.
CCMAIL:99428@bugs.kde.org


 M  +2 -1      kmfolderseldlg.cpp  


--- trunk/KDE/kdepim/kmail/kmfolderseldlg.cpp #429479:429480
@@ -106,6 +106,7 @@
       if ( depth > lastDepth ) {
         // next lower level - parent node will get opened
         item = new FolderItem( lastItem );
+        lastItem->setOpen(true);
       }
       else {
         if ( depth == lastDepth ) {
@@ -135,7 +136,7 @@
     item->setText( mFolderColumn, fti->text( 0 ) );
     item->setProtocol( fti->protocol() );
     item->setType( fti->type() );
-    item->setOpen( fti->isOpen() );
+    item->setOpen( true );
     // Make items without folders and readonly items unselectable
     // if we're told so
     if ( mustBeReadWrite && ( !fti->folder() || fti->folder()->isReadOnly() ) ) {