In Kmail 5.6.3 it was possible to show the message strecture pane by "view -> show message structure". This option is no longer available in 5.7.0. However, it is still needed in some cases, e.g., of malformed/complex mails, to select the right container and it also helps to see/verify the actual mail structure and content (e.g. to see if there is a plain text version).
Looks like it has been moved now, a shortcut is available in the Toolbar. FYI heres the commit: https://cgit.kde.org/kmail.git/commit/?id=24c46184c27407a9224b11697c094d6a71e2cf7c
As wrote in comment 1
I don't think that's acceptable - we can't just have some options "hidden" in the toolbar, especially when they are not enabled by default and not accessible from the menu at all. I had to actually look into the source code to find where the option is, that's simply not something we can expect our users to do... IMO toolbars should be like "favorites". They should contain actions from menus that are very often used by users so that they can just click on the button in the toolbar instead of having to open the menu to get to those actions, but toolbars should *never* hide additional actions that are not accessible from the menu. There's just *NO WAY* users will ever find those options.
For me it's not a end user feature. It's for power user feature. If we want to clean up menu we don't need to add more extra menu entry for power user. There is a shortcut for it, and we can add it from toolbar if we want. Otherwise it's not necessary to try to simplify kmail if we keep some power user feature in menu, for sure I don't use by default this feature.
I use it as an end user, e.g. to verify that a newsletter format of my wordpress instance is correct. I also think, that "toolbar" \subseteq "menu" is a typical pattern and therefore is the expectation of users. Thus, having items randomly appearing only for the on or the other place will only create more confusion. I also do not think that this menu item is very confusing for other users. Alternatively it may be possible to hide advanced features and only show them if you choose the advanced mode? I.e. similar to the vlc approach.
(In reply to Till Schäfer from comment #5) > I use it as an end user, e.g. to verify that a newsletter format of my > wordpress instance is correct. For sure you are the first people which searched it. > > I also think, that "toolbar" \subseteq "menu" is a typical pattern and > therefore is the expectation of users. Thus, having items randomly appearing > only for the on or the other place will only create more confusion. > > I also do not think that this menu item is very confusing for other users. > Alternatively it may be possible to hide advanced features and only show > them if you choose the advanced mode? I.e. similar to the vlc approach. An advanced mode no it will be very hard to test 2 modes. But I can create a plugin (disable by default) which can add action in menu.
*** Bug 388080 has been marked as a duplicate of this bug. ***
Laurent, could you please stop removing or hiding kmail's features which you think are not useful or important? Those features were originally implemented for a reason and kmail's users have been successfully using them for quite some time. If you keep the current pace of downgrading user experience with each subsequent release of kmail, you are going loose existing users of kmail for no real benefit. You should really focus on fixing existing bugs instead of removing existing stable features that nobody complains about.
(In reply to Kamil Dudka from comment #8) > Laurent, could you please stop removing or hiding kmail's features which you > think are not useful or important? > > Those features were originally implemented for a reason and kmail's users > have been successfully using them for quite some time. If you keep the > current pace of downgrading user experience with each subsequent release of > kmail, you are going loose existing users of kmail for no real benefit. > > You should really focus on fixing existing bugs instead of removing existing > stable features that nobody complains about. Just a question: Are you the kmail maintainer ? no I don't think. I am. So if I think that it's better to reduce menu or hide not useful feature for enduser it's my choice. You work on redhat so make your work as packager and stop to cry. Thanks.
I am reopening this bug for the following reasons: 1. Your answer is a clear validation of KDEs Community Code of Conduct [1]: - The answer is not respectful. Quote: "stop to cry" is a clear assault on somebody else who is committed to the project. The code of conduct sais: "We do not tolerate personal attacks"! - Your answer is not considerate. It is no problem to disagree and I would accept a decision you make as a package maintainer. However, having multiple voices, from major open source contributors, that have politely pointed out issues with your position should not be put down without at least a few word acknowledging the others issues and explaining why you still think you position is right. - I also think, even as a maintainer one should not act as a dictator. The code of conduct says: "We value tangible results over having the last word in a discussion." 2. This bug was not fixed. If you do not want to fix the issue, this would go in the category WONTFIX and should be marked as such. [1] https://www.kde.org/code-of-conduct/
It is not important where I work. I am a user of kmail (call me enduser if you like). I do not package kmail for any distribution if that is your concern. I have been using kmail since 2005. Now I have serious doubts about the future of kmail. The problem is that your decisions about removing "not useful" features are not backed up by any facts (like user survey's results). You keep removing features that are considered useful by many kmail's users, which I think is not beneficial for this community project.
Reminder: if we add an option and menu entry each time a user thinks his must-have functionality deserves one, KMail would have a few more buttons bars and countless options in the menu.
*** Bug 393016 has been marked as a duplicate of this bug. ***
(I'll just ignore the last few comments...) I agree with Daniel here. I used the structure view option quite extensively and thought it was removed completely. I'm happy that it's not the case, but it can't just be removed from the menu. The menu needs to be complete, it's the single purpose a menu has.
I have observed, that there is an "expert plugin" for KMail 5.8.0. This plugin re-enables the desired menu option to show the message list structure. I think this is a reasonable solution and for my use case the issue is fixed. There is one smaller aspect I would like to discuss before closing this bug: When the plugin is disabled, it still keeps the shortcut and menu option for "show message structure" accessible. Thus, it still violates the expectation "toolbar" \subseteq "menu". I propose to remove at least the toolbar entry as well, when the expert plugin is disabled. Any objections?
I object. I am tired of the culture that pervades the whole KDE ecosystem (plasma, konqueror, kwin, kmail, kdm, kuser, etc. etc.) in which regressions are considered acceptable. Software is supposed to become more and more user-friendly and feature-rich over time, not the other way around. I have been a faithful KDE user for 17 years, but I have fewer and fewer reasons to stick with it, since many of the features that made me chose it over other Desktop Environments are now removed or broken. The whole kmail2/akonadi is a disaster and I long for kmail1. The regression discussed in this issue is another sad step in the same direction. I understand that developers freely provide their time and expertise for the community, and that their time is limited so that not all bugs can be fixed nor all feature request be implemented. But then why on earth should developers waste their time removing features that were working perfectly?? What so much time and effort wasted on the whole akodani framework which, as far as I am concerned, only brought headaches, weird bugs that at times rendered kmail almost completely unusable, without any apparent benefit in terms of features or usability?? For me, the only acceptable fix to this issue is to revert the commit referenced above.
Why not simply hide features that are considered advanced or expert in a *submenu* called 'Advanced options'. That's what I would expect.
(In reply to stefanprobst from comment #17) > Why not simply hide features that are considered advanced or expert in a > *submenu* called 'Advanced options'. That's what I would expect. This is great solution! I was looking desperately in all menus when this "advanced user" option disappeared. I thought it got removed. How many Kmail features are hidden in the toolbar where no one knows about it?
(In reply to stefanprobst from comment #17) > Why not simply hide features that are considered advanced or expert in a > *submenu* called 'Advanced options'. That's what I would expect. I agree. All features, including ones considered advanced should be discoverable through the interface. It is much easier to peruse the menu tree than to go over the shortcut targets or possible toolbar actions. In any case, I am glad this feature is still there. I had the message structure open at all times and found it very convenient. A configuration option or plugin that enables/disables the ‘advanced menu items’ is fine, as long as that option or plugin is discoverable.
+1 to the comments above. as an end user I use this view option daily. I don't want to prefer HTML mail, but when I get a mail that doesn't display as expected, it is useful to know there is a HTML part to try, if I want to. Please don't remove it - a configure menu -> appearance -> layout option seems to me to be a good place for it to go. It is just as valid as a user pref as e.g. the long/short folder view, IMHO. Kontact 5.8.1 / KF 5.46 / openSuSE 42.3 & update repos.
(In reply to Till Schäfer from comment #15) > There is one smaller aspect I would like to discuss before closing this bug: > When the plugin is disabled, it still keeps the shortcut and menu option for > "show message structure" accessible. Thus, it still violates the expectation > "toolbar" \subseteq "menu". I propose to remove at least the toolbar entry > as well, when the expert plugin is disabled. Any objections? From my point of view, the proposal to remove the toolbar entry if the Expert plugin is disabled is OK.
General comments: 1. AFAICS, KMail seems to be one of the few e-Mail clients which offers an indication of the e-Mail message structure and the size of the message body and the size each attachment. 2. Yes, it is a "nice to have" feature especially, if you're sending e-Mails with potentially large attachments. 3. I suspect that, most human beings haven't the faintest idea as to what the structure of an e-Mail is; which doesn't mean that, the structure of an e-Mail doesn't play a role when considering the consequences of sending e-Mails with a total size of Megabytes or even Gigabytes. Meaning that, if you have colleagues who persist in sending large items as e-Mail attachments (MS Office documents come to mind here -- real-life experience working in large concerns … ) the ability to show them the consequences of their actions and, possibly, retrain them, is much easier if the e-Mail structure can be displayed. Please note that, the above comment doesn't work for the case of managers -- they tend to be extremely resistant to "on the job" schooling … ;-)
Interesting discussion and opinion exchange. So, I dare to add a comment from an experienced end user's perspective. I have used KDE/Kmail for over 12 years now. I have used it as a part of my daily professional Linux/KDE/Kontact working environment - with accounts on many different Mail- and groupware servers. So, as an end user have I followed all the ups and downs of this application. Parts of my family use it, too. And to make it clear from the beginning: I do respect respect the developers' effort. Very much so. I am 60 years old and I have worked in IT for over 30 years - as a developer, as an application designer, as project leader, as a consultant. In agile environments - and with maintainers. As an interested end user with respect to Kmail I can only express my deepest dislike of attitudes as: "So if I think that it's better to reduce menu or hide not useful feature for enduser it's my choice." No, dear maintainer, it is NOT! A maintainer has to work in the interest of both the developers AND the end users. Deciding what is useful for an end user or not is, however, a difficult process - which, of course, should involve the end user. Certainly, it is not something which can be decided upon in a nice developer chat, only. I do not assume that this was the case here, but I stress this point to make clear that it is not just simply "your" choice. Changing or even removing elementary features should be the result of a careful analysis. It would have been helpful to see how the maintainer came to his conclusions and on what basis the end users opinion was taken into account. I, myself, have worked in the interest of end users in some SW projects. And you know what? The most annoying thing for an end user is: Changes and changes and changes with an unclear or dubious motivation - and without even a minimum end user survey. (In the case of Kmail besides technical problems and not properly working features - as the search for mails with AND/OR conditions in Kmail for years.) But even more annoying is the removal of features. And I may tell you - even if some developers and maintainers may not believe it: To have a look at the structure of an email has become something elementary for security aware end users. An important thing for the success of an application is a balance of keeping up things users got used to and improvements/extensions. One key experience in application design is: This balance between conservative maintenance and innovation is a delicate one for customers. And one rule, I painfully had to learn myself, is: You do not simply remove options users were used to for years without proper replacement! In addition: CLEANING UP MENUS may be a great thing to do if it follows a comprehensible logic. REMOVING FEATURES without a replacement certainly IS NOT! You should note that you are talking about two very different things. As an end user I vote for a kind of "advanced options" menu. That is a place where most users would look for a replacement of options that suddenly have disappeared. A plugin, instead, makes life for end users more complicated. You have to know about plugins and their handling. You have to activate them and maybe configure them. In my opinion not convincing for elementary options as displaying the mail structure.
The reason why I commented at all (see comment 23) was that my wife got a spam/malware mail which showed no contents in the "new" Kmail. I said : Look at the mail's structure. She said: hey, there is no option for this any longer. The mail had an HTML part, clearly shown in its structure view => Which we could have a look at only after we found out that the option really had disappeared from the menu structure and was purposefully hidden in the configuration options for the task bar. A "V" for the code of the mail then revealed the shit in it. So, for reacting properly to some dubious mails it is helpful to have a display of their structure - and an option for setting this display to "on" permanently.
(In reply to Laurent Montel from comment #9) > (In reply to Kamil Dudka from comment #8) > > Laurent, could you please stop removing or hiding kmail's features which you > > think are not useful or important? > > > > Those features were originally implemented for a reason and kmail's users > > have been successfully using them for quite some time. If you keep the > > current pace of downgrading user experience with each subsequent release of > > kmail, you are going loose existing users of kmail for no real benefit. > > > > You should really focus on fixing existing bugs instead of removing existing > > stable features that nobody complains about. > > Just a question: > Are you the kmail maintainer ? > no I don't think. > I am. > > So if I think that it's better to reduce menu or hide not useful feature for > enduser it's my choice. > > You work on redhat so make your work as packager and stop to cry. > > Thanks. Dear maintainer, There is another problem with your "choice" here: The documentation did not reflect this change! That's an absolute no go! I'm currently looking for some other bug in Kmail/Akonadi and reading the mailing-list archives. I discovered this bug report by chance now. Some time ago I (as an end-user) needed to look up the message structure of one mail. I was very upset as I saw the menu entry I knew was there for years was gone. I tired to "google" for this issue but did not find this bug report then. I also did not find any information about a removal of this feature. The documentation says it is still in the menu! I thought it is a very strange bug. I even started to look for the relevant code in Kmail (but did not push this endeavor any further than out of lack of time). In the end I exported the raw mail an used some tools on it to extract the part of the mail I was interested in. Looking into this issue and coming up with a workaround was a waste of several hours! "Hiding" or removing features "for power users" is a think I would expect form the Gnome people. But never ever from a KDE app! Please don't do something like that again! There are some usability standards under KDE now for years: Everything you can find in the GUI is also available as a toolbar. But not the other way around! Till said: "'toolbar' \subseteq 'menu' is a typical pattern". I think it's not only a "typical pattern" it's how things work all over KDE apps since most likely pre V1.0 versions. (Maybe I don't recall correctly the version but it works like that since "ever")! It's not anything you could make a "choice" about. You just wasted the time of several people by making a "choice" like that. But there was no gain whatsoever in doing so! KDE isn't for people who like "hidden" or striped down features. Thank you for being now aware that with "choices" like that you will annoy a lot of long time KDE users. Best regards, Mateusz
Closing, the option is available in the "Message" menu after enabling the "Expert" plugin.
(In reply to Christophe Giboudeaux from comment #26) > Closing, the option is available in the "Message" menu after enabling the > "Expert" plugin. Can you fill in the ‘Version fixed in’ field so that we know when it'll be available to us on distribution update schedules?
(In reply to Erik Quaeghebeur from comment #27) > Can you fill in the ‘Version fixed in’ field so that we know when it'll be > available to us on distribution update schedules? Done, the plugin is in the kdepim-addons repository.