Bug 179711 - Dragging message to folder w/ subfolders does not expand folder
Summary: Dragging message to folder w/ subfolders does not expand folder
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail
Classification: Unclassified
Component: new folder tree (show other bugs)
Version: 1.10.92
Platform: Compiled Sources Linux
: NOR normal with 115 votes (vote)
Target Milestone: ---
Assignee: Szymon Stefanek
URL:
Keywords:
: 180422 180738 182687 188084 195586 198071 204337 225053 228149 228274 229100 229533 233767 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-05 14:27 UTC by Gregor Petrin
Modified: 2013-11-16 13:17 UTC (History)
22 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gregor Petrin 2009-01-05 14:27:37 UTC
Version:           1.10.92 (using Devel)
OS:                Linux
Installed from:    Compiled sources

This is a regression, as the functionality was present in older versions (i.e. before the version that introduced tabs). When dragging a message from the message list over a closed folder A that contains subfolders (e.g. AB and AC), this folder no longer auto-opens. So if I had wanted to move the message into subfolder AB, I would have to abort the drag operation, manually open folder A and repeat the drag operation.

On the plus side, while searching if this bug was already reported, I have learned about the M shortcut, which might well replace my dragging needs - great job (reminds me of the Nostalgy plugin for Thunderbird, only better implemented). Still, a feature that used to work but no longer works can annoy people..
Comment 1 Martin van Es 2009-01-05 20:40:05 UTC
I can confirm this regression (kde 4.1.85, beta2) and also experience this as a loss.
Just tried 'm' and must admit... that looks promising.
Comment 2 Jaime Torres 2009-01-19 09:40:35 UTC
*** Bug 180422 has been marked as a duplicate of this bug. ***
Comment 3 Ralph Moenchmeyer 2009-01-20 16:21:17 UTC
The 'm' shortcut is great. However, I think that the 'old' feature still should be offered. There are many who are used to work with dragging emails to a folder .....     
Comment 4 Dario Andres 2009-03-25 18:56:00 UTC
*** Bug 188084 has been marked as a duplicate of this bug. ***
Comment 5 Silver Salonen 2009-06-03 13:48:50 UTC
I've missed since it went away.. I'm often forced to just open the folders manually now before starting to move a message under a subfolder :(
Comment 6 Szymon Stefanek 2009-06-06 05:44:29 UTC
This feature is present in the sources but has been commented out
due to a bug in Qt introduced with the new QTreeView.
The fact is that the folders auto open but _also_ auto close:
and this is extremely confusing.

In August 2008 I have submitted a bug report about this but
it's still there marked as "pending"...

http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=221916

Maybe if you push it a little bit... :D
Comment 7 Silver Salonen 2009-06-06 08:14:42 UTC
I don't see the auto-collapsing as a bad thing, but rather useful. There's actually another feature request for this - ID 78338 :)

But while Qt ain't fixing the bug, maybe the feature should be made available through some setting or smth?
Comment 8 Adrien Cordonnier 2009-06-06 13:17:26 UTC
(In reply to comment #6)
> This feature is present in the sources but has been commented out
> due to a bug in Qt introduced with the new QTreeView.
> The fact is that the folders auto open but _also_ auto close:
> and this is extremely confusing.
> 
> In August 2008 I have submitted a bug report about this but
> it's still there marked as "pending"...
> 
> http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=221916
> 
> Maybe if you push it a little bit... :D

Szymon, commenting the code to hide this Qt "bug" won't help. For the last 5 months, nobody here knew it came from Qt and that must be the reason why it is still pending.

And I will *not* push the Qt bug because as Silver says, I may like this auto-collapsing feature but I cannot tell until the code is uncommented so that I experience it.
Comment 9 Szymon Stefanek 2009-06-06 15:36:00 UTC
It's easy to try it out. kdepim/kmail/folderview.cpp , line 180, change

  //setAutoExpandDelay( gDNDAutoExpandDelay );
  setAutoExpandDelay( -1 );

to

  setAutoExpandDelay( gDNDAutoExpandDelay );
  //setAutoExpandDelay( -1 );

and rebuild.
Comment 10 Thomas McGuire 2009-06-06 15:41:26 UTC
I find auto-collapsing totally annoying, and think it should not be enabled because of this.
Comment 11 Silver Salonen 2009-06-06 20:15:47 UTC
I suggested it to be enabled through some setting, because that way you can disable the auto-expanding if you don't like it when it goes along with auto-collapsing.

Afterwards the setting can be left there as more possibilities for customization is always nice :)

PS. I'd also like the auto-collapsing as a separate setting.
Comment 12 Adrien Cordonnier 2009-06-07 00:39:35 UTC
I can't test (no idea how to rebuild) but as far as I understand the qtreeview.cpp code, indeed it is not the expected behaviour (I would expect auto-collapsing only for auto-expanded folders and if we go away from them and their subfolders)

So how can we push for the Qt bug to be solved? I don't see how to put comments.

Can't we use something else than qtreeview? Konqueror still has the behavior we were used to (e.g. in the personal folder view in the left navbar). Implementation may be kfiletreeview (which is derived from qtreeview).
Comment 13 Szymon Stefanek 2009-06-07 03:30:48 UTC
As far as I can see, the konqueror sidebar is based on K3ListView, that is, it still relies on Qt3Support. That's why the expansion works as expected in konqy. 

Have no idea on how to push on trolltechs on this.. maybe by reporting the same issue multiple times from different users ? :D

Another option might be to ask someone who is taking care of the qt-copy module. Maybe a patch could be added there...it's quite trivial. But since this is not a critical issue then I suppose that there must be really enough interest.
Comment 14 Silver Salonen 2009-06-07 12:01:24 UTC
(In reply to comment #12)
> I can't test (no idea how to rebuild) but as far as I understand the
> qtreeview.cpp code, indeed it is not the expected behaviour (I would expect
> auto-collapsing only for auto-expanded folders and if we go away from them and
> their subfolders)

We ARE talking about auto-expanding folders here, aren't we?
Comment 15 Thomas McGuire 2009-06-07 14:39:29 UTC
> Another option might be to ask someone who is taking care of the qt-copy module. Maybe a patch could be added there...it's quite trivial. But since this is not a critical issue then I suppose that there must be really enough interest.

If you really want to go through the trouble: Qt development is totally open nowadays, simply clone their git master tree, write a patch and submit that as a merge request, see http://qt.gitorious.org/qt.
qt-copy will soon be removed.
Comment 16 Thomas McGuire 2009-06-07 19:43:57 UTC
*** Bug 195586 has been marked as a duplicate of this bug. ***
Comment 17 FiNeX 2009-06-28 11:13:58 UTC
*** Bug 198071 has been marked as a duplicate of this bug. ***
Comment 18 FiNeX 2009-08-19 00:02:47 UTC
*** Bug 204337 has been marked as a duplicate of this bug. ***
Comment 19 Christophe Giboudeaux 2009-11-18 21:58:52 UTC
*** Bug 182687 has been marked as a duplicate of this bug. ***
Comment 20 Christophe Giboudeaux 2009-11-18 22:02:03 UTC
*** Bug 180738 has been marked as a duplicate of this bug. ***
Comment 21 Dana Whicker 2009-11-19 05:41:48 UTC
*** This bug has been confirmed by popular vote. ***
Comment 22 Silver Salonen 2010-02-10 15:26:01 UTC
Any activity on this front?
Comment 23 Wallaby Pouch 2010-02-20 23:02:47 UTC
Is it possible to get a fix for this in a coming update?
This issue is bugging me for a very long time now, probably years. The last time it worked was KDE 3.x I think.
Comment 24 Björn Ruberg 2010-03-13 14:53:32 UTC
*** Bug 225053 has been marked as a duplicate of this bug. ***
Comment 25 Björn Ruberg 2010-03-13 14:53:57 UTC
*** Bug 229533 has been marked as a duplicate of this bug. ***
Comment 26 Björn Ruberg 2010-03-13 16:09:06 UTC
*** Bug 228149 has been marked as a duplicate of this bug. ***
Comment 27 Björn Ruberg 2010-03-13 16:10:36 UTC
*** Bug 228274 has been marked as a duplicate of this bug. ***
Comment 28 Björn Ruberg 2010-03-13 16:23:54 UTC
*** Bug 229100 has been marked as a duplicate of this bug. ***
Comment 29 Björn Ruberg 2010-04-14 23:08:43 UTC
*** Bug 233767 has been marked as a duplicate of this bug. ***
Comment 30 Arthur Pemberton 2010-04-15 00:03:14 UTC
Could someone please explain what is going on with this bug? Originally I thougth that this was just a bug, but from my first reading of this entire thread, it looks to be one line of code that has been commented out.

According to the Qt bug linked to, any folder that auto-expands will later auto-collapse. While one can argue whether that makes sense or not, if it only affects auto-expanded folders, please enable this and let us take up the new issue with Qt as to if this makes sense. It's been over a year for what apperently is one line of code. So I'm kinda curious: regorganizing email is bit more of a pain now that I have to remember to pre-open folders.
Comment 31 Martin L ü c h e m 2010-04-15 08:00:34 UTC
Hello Developers,

I think it is correct to complain! :-(

I have been using KMail since 1999 and through the years it became my favorite 
application in KDE. Up to the switch to KDE 4. From now on there is pain and I 
wonder why.

This "bug" - or was it a design decision? - makes handling/reorganizing of 
mails and folders very difficult but nothing happens to improve the situation. 

Talking about changes in the architecture: KMail is not the only application 
in KDE where nowadays there is argued like that: This is a change in an 
underlying technology so we cannot help. Well the people who have been using 
the software and who have liked the software for years can be blamed to switch 
to KDE 4 but they simply do not understand why KMail and other main 
applications - Konqueror in general and the bookmarks, Amarok and Phonon, 
Kalender in general, etc. - were made worse instead of better and why these 
typical problems persist. (Back to KMail: Still problems with IMAP and the 
application eats RAM what it never did before.)

So please help because the people around the world that use Linux and KDE 
probably continue to use it because they like the project and the people 
working on it.

Sorry for the "Wort zum Sonntag" you can forward it to the KDE development 
coordinators! ;-)

Martin

Am Donnerstag, 15. April 2010, um 00:03:20 schrieb Arthur Pemberton:
> https://bugs.kde.org/show_bug.cgi?id=179711
> 
> 
> 
> 
> 
> --- Comment #30 from Arthur Pemberton <pembo13 gmail com>  2010-04-15
>  00:03:14 --- Could someone please explain what is going on with this bug?
>  Originally I thougth that this was just a bug, but from my first reading
>  of this entire thread, it looks to be one line of code that has been
>  commented out.
> 
> According to the Qt bug linked to, any folder that auto-expands will later
> auto-collapse. While one can argue whether that makes sense or not, if it
>  only affects auto-expanded folders, please enable this and let us take up
>  the new issue with Qt as to if this makes sense. It's been over a year for
>  what apperently is one line of code. So I'm kinda curious: regorganizing
>  email is bit more of a pain now that I have to remember to pre-open
>  folders.
>
Comment 32 Ralph Moenchmeyer 2010-04-16 10:15:00 UTC
I want to strongly support the point made in comment 30: 

Reactivate the auto-expand - and please, do it at once !

I use Kmail on a daily basis for business purposes. For quite a while I have tried to use the 'm'-feature instead of dragging and dropping. However, it does not feel natural. I is just a useful additional option for moving mails but not really efficient.   

For me the "old" behaviour - an automatic expansion of the folder I drag to - is what the user expects. Especially if the folder structure has more than just 2 levels. All other solutions have disadvantages regarding useability, keeping an overview and of course regarding time.  

And I may add that it is a feature all other major mail systems offer. 

I understand that there is a bug in Qt which leads to auto-collapse. What happened with this bug ? And why isn't there a way to circumvent by some own programming ?
Comment 33 Silver Salonen 2010-04-16 10:28:55 UTC
(In reply to comment #32)
> I understand that there is a bug in Qt which leads to auto-collapse. What
> happened with this bug ? And why isn't there a way to circumvent by some own
> programming ?

As I've already written, I see this "bug" as a feature instead, because I would really like auto-expanding folders to collapse afterwards. But as not everyone would like it, I still suggest making an option for that into KMail settings (under Appearance -> Layout).
Comment 34 Arthur Pemberton 2010-04-16 10:38:37 UTC
(In reply to comment #32)
> Reactivate the auto-expand - and please, do it at once !

While I understand that you may consider this very urgent, some may take offence to the tone, so consider software language.

> I understand that there is a bug in Qt which leads to auto-collapse. What
> happened with this bug ?

The one that was linked to at least got closed due to inactivity: no one in Qt fixed it, and no one else complained about it.

> And why isn't there a way to circumvent by some own programming ?

Qt hasn't (yet?) amended their API to allow it.
Comment 35 Martin L ü c h e m 2010-04-16 11:08:03 UTC
Hello Arthur,

to say it in clear worlds: Nothing happens - a pity!

By the way, is this the same or a similar bug as within the konqueror bookmark 
manager. In this application there is no moving at all!  The effect is even 
worse: Bookmarks are becoming senseless because you cannot reorganize them. 
And this is similar to KMail. Now the question is: When the handling of an 
application - in this case reorganization of mails and folders - in a later 
release is getting worse instead of better, is this a BUG or not? 

I would call this a bug but for sure it would be unfair to blame the 
developers of KMail. The people that should focus on this are 
architects/coordinators of the KDE projects or some kind of "product 
managers"?

Regards, Martin

Am Freitag, 16. April 2010, um 10:38:51 schrieb Arthur Pemberton:
> https://bugs.kde.org/show_bug.cgi?id=179711
> 
> 
> 
> 
> 
> --- Comment #34 from Arthur Pemberton <pembo13 gmail com>  2010-04-16
>  10:38:37 --- (In reply to comment #32)
> 
> > Reactivate the auto-expand - and please, do it at once !
> 
> While I understand that you may consider this very urgent, some may take
> offence to the tone, so consider software language.
> 
> > I understand that there is a bug in Qt which leads to auto-collapse. What
> > happened with this bug ?
> 
> The one that was linked to at least got closed due to inactivity: no one in
>  Qt fixed it, and no one else complained about it.
> 
> > And why isn't there a way to circumvent by some own programming ?
> 
> Qt hasn't (yet?) amended their API to allow it.
>
Comment 36 Arthur Pemberton 2010-04-16 11:17:04 UTC
(In reply to comment #35)
> By the way, is this the same or a similar bug as within the konqueror bookmark manager

I don't know, I don't use Konqueror.

> And this is similar to KMail. Now the question is: When the handling of an 
> application - in this case reorganization of mails and folders - in a later 
> release is getting worse instead of better, is this a BUG or not? 

Well, for the purposes of reporting to the developers, I think that it is fair to classify this as a bug.

> I would call this a bug but for sure it would be unfair to blame the 
> developers of KMail

Well I'm not concerned about assignment blame, just want to get on with using the programs to get work done. I already have to go with Akonadi since it has decided to disable my Address book. And tonight KMail stopped quoting emails when I hit 'reply'. So the problems in the KDE Pim suite of applications is just piling up for me, and this is my primary machine and desktop, so I have no other platform to use.
Comment 37 Ralph Moenchmeyer 2010-04-16 12:59:42 UTC
(In reply to comment #34)
> (In reply to comment #32)
> > Reactivate the auto-expand - and please, do it at once !
> 
> While I understand that you may consider this very urgent, some may take
> offence to the tone, so consider software language.
> 

I apologize for my bad English, no offence was intended. I expressed myself badly. And probably there is no one to blame. 

I wanted to say that I as a normal user whose daily work depends heavily on  Kontact/Kmail have the whish that this kind of "regression bug" is solved as soon as this is technically possible. And I think I have good reasons for my whish. I have tried alternatives but I find that the situation before the "bug" was better and that the suggested alternatives do not support the user's workflow as well as the program already did in the past.

I hope this is agreeable ? 
   
I know very well that there are a lot more things for a developer to consider than I as a standard user see and focus on. And I accept that the process for error correction or feature changing takes its time especially with respect to open source products.

However, when you depend on an open source product in a productive environment and you have to deal not only with one but several time consuming "regression or feature problems" again and again  - it is no funny situation either. And it makes the release policy within a company very complicated. Therefore, I can e.g. very well understand the points Martin Lüchem describes.   

Sometimes some problems remain open for months and over major release changes. And there are some classes of "little" bugs that can drive a user to the point when you just want to give up and just begin using another program. I may say this from over 10 years experience with Opensource enviroments.  

I know this kind of discussion is off the purpose of this bug tracker - but maybe it helps to see why the continuous handling of small "bugs or features", which change a product from good to worse in the eyes of a user, is so important. So one more example :   

I, too, ran into the Akonadi related problems with the adressbook - it took me hours to understand what happened why and how to resolve the problems with the adress book. Eventually, I only understood what was going on by following a continuous discussion of a really desperate (!) user with some KDE developer over several pages in a forum - until the developer understood why the user had a problem at all and the user understood that the Kontact Akonadi adressbook presently was not intended to be used in Kmail and that he had to generate separate "old" adressbooks for Kmail. To circumvent the problem then was simple - but you ask yourself: how could such fatal misunderstandings come about at all? Why is the user suddenly confronted with the consequences of a "design" decision which he has no chance to understand or handle but which is fatal for his daily work?  

At that point in time the Akonadi problems on a test system had already influenced a key decision in my company not to move to KDE 4.4. So problems which may seem small and limited to a developer can have much wider effects than they may expect.    

And therefore I very well understand why some users want to see a "product manager" as Martin Lüchem describes it.   

But again ....  I am really sorry for the unintended harsh tone .....
Comment 38 FiNeX 2010-04-16 16:02:25 UTC
> However, when you depend on an open source product in a productive
> environment and you have to deal not only with one but several time
> consuming "regression or feature problems" again and again  - it is no
> funny situation either. And it makes the release policy within a company
> very complicated. Therefore, I can e.g. very well understand the points
> Martin Lüchem describes.

Hi, this comment makes me thing again about a consideration I've done in the 
past. Maybe it could be the start of an interesting discussion (not a flame):

being KDE, like all other free software projects, a community driven software, 
where the satisfaction of the end user is not directly proportional with an 
economical earning, so the "customer satisfaction" is not the main target, _ a 
big, big, big warning should be printed on the home page of all the free 
software projects informing end users that the software is not intended to be 
installed and used in a company unless who use it doesn't exactly know what 
he's doing. _
The warning should be given unless my hypothesis (customer satisfaction and 
other suffs) is not right, for example due to an explicit decision made by the 
developers and mantainers of that specific project which could be 
intentionally developed for being used in a working enviroment.

What do you think about my old thoughts?

> I, too, ran into the Akonadi related problems with the adressbook - it took
> me hours to understand what happened why and how to resolve the problems
> with the adress book.
> [...]

This is why I really hope that KDE SC 4.5 will not break the PIM and, if it 
wouldn't be a smooth transition, a huge warning should appear on the KDE 
webiste :-) :-) :-)

Anyway this time I'm quite OT... :-p :-p :-p


Regards.
Comment 39 Martin L ü c h e m 2010-04-16 17:10:26 UTC
Hello FiNeX,

Am Freitag, 16. April 2010, um 16:02:31 schrieb FiNeX:
> The warning should be given unless my hypothesis (customer satisfaction
>  and  other suffs) is not right, for example due to an explicit decision
>  made by the developers and mantainers of that specific project which could
>  be intentionally developed for being used in a working enviroment.
> 
> What do you think about my old thoughts?
> 

/OT

Absolutely correct! But:

1. Can you tell me which version of Linux/KDE on the Desktop ever reached this 
status?

2. Can you tell me, if it will be possible that Linux/KDE will ever reach this 
status? Especially on Notebooks!

-> We all know that mostly we have to run our Notebooks in a testing 
environment if we want to use up-to-date functions on it and connect modern 
hardware. The main problem are the decision takers of these hardware 
manufacturers!

3. Why was KDE 4 ever released under this name? Why did noone release it as 
e.g. KDE 4.1 Alpha and 4.3 Beta and so on?

4. The main point: Working with Linux since 1999, never having been a 
developer but often a friend to Linux consultants (yes, I worked for SuSE some 
days!) I cannot stop to believe that a lot of people in the community would 
prefer to develop without this funny type of person called "user". Too often 
after having trying to explain my problems with the system I am told: "If you 
want to improve the situation than start to develop!"

-> Ok, funny discussion in here and it was my fault as well! :P

/OT End

By the way: Thanks to the thousands of people that develop this interesting 
piece of software!!!! I never stopped to believe in it - up to now.

:-) :-) Martin
Comment 40 Ralph Moenchmeyer 2010-04-16 20:31:13 UTC
/OT 

(In reply to comment #38)
> 
> What do you think about my old thoughts?
> 

I think that the community - and I include the users as well ! - should get used to the fact that nowadays even open source programs for the desktop are used not only because of the fun factor but for real daily business work. Surprise, surprise - but wasn't that the purpose of all the effort ? 

In my opinion this means that the production and release process in the open source community may have to change. Basically, it requires a more critical and organized contribution of the users. But it's work on the user's side - we knew and know the risk of acting as permanent beta-testers. That was our role so far. 
So, let us organize the quality assurance in a better and more convincing way. This includes building up a new layer between the developers and the end users - in the interest of the developers as well. Because, I still believe that developers like users who smile and get motivated when these funny users love the results of the development 

.... and despite all the problems - I like KDE 4.X and I like Kmail and hope for the best regarding KDE'S 4.5 PIM ... this is why I complain sometimes ... 

But to rely on distributers like Novell/SUSE to get consistent and high quality software and continue as beta-testers will not be enough in the future ....       

OT/
Comment 41 Daniel Hahler 2010-04-17 12:22:55 UTC
I have added this patch to the Kubuntu KMail package (via https://code.edge.launchpad.net/~blueyed/ubuntu/lucid/kdepim/329659-autoexpand-kmail-folders/+merge/23572), and it does not work: auto-expanding is still not done when hovering over an item.

Szymon: have you tested it yourself when you proposed this patch? (comment 9)
Comment 42 Daniel Hahler 2010-04-17 12:23:51 UTC
(not the official package, just test-built locally for now)
Comment 43 envite 2010-08-24 14:39:20 UTC
I have just bought a new computer and installed KDE 4.4 in it (from Debian testing=squeeze). I was accustomed too to the workflow of moving mails to a collapsed folder and having it open when hovering some seconds.

The 'm' shortcut is not the solution (nor even a workaround) here, because in real environments the completely uncollapsed list of folders can be very very long, so you can lose more time in the 'm' window than you will spend in aborting the moving, hand-opening the closed folder and moving again.

I know that KDE 4 being a complete new environment based on a complete new library can be a nightmare for developers, but regressions like this are a nightmare to users.

Things like this bug, the IMAP problems, or the long-standing problem about wallpapers make me don't want to recommend KDE 4 to anybody (and KDE 3.5 will not available anymore when the freezed squeeze become stable). Truly, I will not upgrade my father's computer, and will keep my mother's one with Gnome, becouse they want things that "just works" and that "doesn't change behaviour once I've learned to use".

Would it be really so difficult for you to clone the Qt repo, patch the Qt 'bug', and patch this kmail regression? I know it will be for me, but I'm not a programmer. But I can not think it can be so difficult for you, seasoned developers.

Moreover, auto-collapsing would be a very good thing, just providing it does not collapse while you're still operating on it.
Comment 44 20120808_bugs.kde.org 2010-08-29 18:01:32 UTC
and yet moving pictures in digikam (v1.3; kde 4.5) provides for auto-expanding folders (do not appear to collapse back though)
Comment 45 Steve 2010-09-30 20:50:43 UTC
I reported this bug in the OpenSuse bugzilla yesterday and it got closed as UPSTREAM.

The bug has also been migrated to JIRA  

http://bugreports.qt.nokia.com/browse/QTBUG-2553

but nothing seems to have happened there either :-(
Comment 46 Ralph Moenchmeyer 2011-08-01 16:04:42 UTC
Last weekend I updated my Opensuse 11.4 system from KDE 4.6 to KDE 4.7. 

Up until a week ago Suse's "factory repository for KDE 4.6" had included Kontact, Kmail and other KDEPIM applications only in an "old" version released for KDE 4.4. 

So my update to KDE 4.7 via the Opensuse repository was a big jump from Kmail 1.13.x for KDE 4.4 to Kmail 4.7.         

And I couldn't believe my eyes - the present Kmail version remedies regression bug #179711:  

Dragging emails to folders/subfolders now opens the folders! (again, I may say after 1,5 years since this bug was opened ...) 

So, eventually, this bug probably can be closed - at least (or even?) for Opensuse 11.4 users, who upgrade KDE via Suse's KDE factory repository.
Comment 47 FiNeX 2011-08-01 16:48:49 UTC
The bug is reproducible using debian pacakges (KMail 1.13.7, KDE 4.6.5).
Comment 48 Ralph Moenchmeyer 2011-08-01 17:58:36 UTC
Regarding Comment #47: 

  > The bug is reproducible using debian packages (KMail 1.13.7, KDE 4.6.5).

FiNeX, I agree. Checked it on a different Opensuse 11.4 system with KDE 4.6.5 and Kmail 1.13.7. 

However, for KDE 4.7 and Kmail 4.7 the bug is no longer existent. At least it does not exist on my Opensuse 11.4 system any longer. 

(Off topic: There are other new Kmail bugs, however)
Comment 49 FiNeX 2011-08-01 19:23:39 UTC
@Ralph: with Kmail 4.7 do you mean Kmail 2 ?
Comment 50 Ralph Moenchmeyer 2011-08-01 20:13:02 UTC
Answer to comment #49: 

 > @Ralph: with Kmail 4.7 do you mean Kmail 2 ?

If you had asked me during the time of KDE 4.6 I would have said YES. 

However, looking at the version information under the Help Menu/About ... in Kmail or Kontact I see :

KMail
Version 4.7.0 
Unter KDE 4.7.00 (4.7.0) 

and 

Kontact
Version 4.7.0 

So, it seems that the KDE developers aligned the Kontact/Kmail version numbers with the KDE version.
Comment 51 FiNeX 2011-08-01 20:58:01 UTC
@Ralph: so I suppose it's the Akonadi based version right?
Comment 52 Ralph Moenchmeyer 2011-08-01 21:36:43 UTC
Answer to comment #51: Yes
Comment 53 Chao Feng 2013-11-16 13:17:02 UTC
Kmail is unmaintained. Issue not exist in kmail2.