Kmail doesn't expand folders when dragging

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..

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.

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

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 .....

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

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 :(

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

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?

(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.

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.

I find auto-collapsing totally annoying, and think it should not be enabled because of this.

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.

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).

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.

(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?

> 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.

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

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

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

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

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

*** This bug has been confirmed by popular vote. ***

Any activity on this front?

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.

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

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

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

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

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

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

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.

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.
>

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 ?

(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).

(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.

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.
>

(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.

(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 ...

> 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.

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

/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/

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)

(not the official package, just test-built locally for now)

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.

and yet moving pictures in digikam (v1.3; kde 4.5) provides for auto-expanding folders (do not appear to collapse back though)

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 :-(

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.

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

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)

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

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.

@Ralph: so I suppose it's the Akonadi based version right?

Answer to comment #51: Yes

Kmail is unmaintained. Issue not exist in kmail2.