Bug 399245 - Restore UI functionality related to "Show HTML side bar"
Summary: Restore UI functionality related to "Show HTML side bar"
Status: CONFIRMED
Alias: None
Product: kmail2
Classification: Applications
Component: UI (show other bugs)
Version: Git (master)
Platform: Other Linux
: NOR wishlist with 182 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 412190 421936 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-09-30 16:11 UTC by pqz
Modified: 2022-10-13 15:21 UTC (History)
19 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 pqz 2018-09-30 16:11:57 UTC
After updating Kmail to 5.8.0, it is no longer possible to hide the "HTML side bar". In KMail 5.7.3 there is a checkbox (Show HTML side bar) in the Setting dialog, in Appearance -> General.

This was reported as bug 393595 and bug 393421 (closed), but as requested by christophe@krop.fr, reopening again as a "feature request".
Comment 1 Störm Poorun 2018-09-30 16:34:03 UTC
Great. Though it's not clear why the previous bug couldn't be converted to a 'feature request' and re-opened?

That would be preferable given the subscribers and comments are already associated with that Bug.

https://bugs.kde.org/show_bug.cgi?id=393421


When most Users use their email app they do not expect to 

a) view on each email a hideous line which should have stayed in the 1990s, which a user may not need and can't turn off

b) view a warning box on each email, which can't be turned off (except on each email individually).
"Note: This HTML message may contain external references to images etc. For security/privacy reasons external references are not loaded. If you trust the sender of this message then you can load the external references for this message by clicking here."

This is an affront to Users a terrible impact on workflow, those dealing with casual email will find it intrusive enough. Those dealing with thousands of messages a day do not need that message in a red box taking priority on each email they read.

There needs to be settings:
a) in the menu (like there was previously) to hide the warnings
b) in the menu to display html
c) in a pop up if a user closes the message, enable them to hide the warnings in future
d) in a pop up if a users chooses to view .html mail, to permit them to autodisplay .html mail in future
e) make the toggle bar less intrusive and less abrubt
Comment 2 Erik Quaeghebeur 2018-09-30 17:48:42 UTC
(In reply to pqz from comment #0)
> After updating Kmail to 5.8.0, it is no longer possible to hide the "HTML
> side bar". In KMail 5.7.3 there is a checkbox (Show HTML side bar) in the
> Setting dialog, in Appearance -> General.
> 
> This was reported as bug 393595 and bug 393421 (closed), but as requested by
> christophe@krop.fr, reopening again as a "feature request".
There is some misunderstanding here. First, *I* suggested you open a new bug. Second, I suggested that you open a feature request bug for your UI *modification* suggestions, not for the reinstatement of the existing configuration option, which is bug 393421. Currently, this is just a duplicate of that bug. Please read the comments more carefully to avoid duplication of effort.
Comment 3 pqz 2018-09-30 18:19:38 UTC
Sorry for the name (author) related misunderstanding (for some reason I though you are one of the git committers, but I admit I did not check git logs). 

The current ticket does not reinstate bug 393421, is just describing the situation created by the change in the standard (default) settings dialog. The ticket does not suggest to restore the previous code, is just asking for a way to achieve the same functionality and that may be through a plugin or direct in standard settings dialog.

What is the "duplicated effort" here? We mean somebody will "work" again then "triage" and close this ticket also ? Can we stop focusing on how is this issue reported and instead focus on the reported problem?
Comment 4 Christophe Marin 2018-09-30 19:11:48 UTC
Making noise just wastes everyone's time.

Erik's suggestion was correct. The question is not whether this option should come back or not, the maintainer already said it won't.

Suggesting UI changes *is* the way to go.
Comment 5 pqz 2018-10-02 00:15:22 UTC
(In reply to Christophe Giboudeaux from comment #4)
> Making noise just wastes everyone's time.
> 
> Erik's suggestion was correct. The question is not whether this option
> should come back or not, the maintainer already said it won't.
> 
> Suggesting UI changes *is* the way to go.

You should learn to respect other people opinions. "Making noise" is not an appropriate language and/or attitude.
Comment 6 Christophe Marin 2018-10-02 08:18:41 UTC
I can close as duplicate of the other bug report where most comments can be reduced to "+1" if you prefer.
Comment 7 avlas 2018-10-29 21:24:15 UTC
What about start improving the UI by fixing this https://bugs.kde.org/show_bug.cgi?id=393421#c47

In brief, the colors of the html bar have no effect in Kontact
Comment 8 shevegen 2018-12-08 16:37:29 UTC
(In reply to Christophe Giboudeaux from comment #6)
> I can close as duplicate of the other bug report where most comments can be
> reduced to "+1" if you prefer.

While you could reason that way, the problem is that the other thread has lots more comments than the one here, so this is not ideal for discussions.

I think it may have been better to mark the original one as a feature request and keep it open. Nobody would force xyz or you to work on it - it would just be one feature request of many more (or, in the event that it removed existing functionality, a regression, in which case the question is whether developers should have a higher right to modify code that affects the users, and I think the users should have a higher right if it comes to any functionality that has been working at some point. Losing functionality is always bad.).
Comment 9 pscholz 2019-01-24 22:28:53 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 Konrad Rzepecki 2019-02-05 10:20:23 UTC
I just begin to test KDE5/Plasma, and I definitely want to have option to remove this crappy bar!!!

I have problem with enable message structure which you also want to remove. In bug 387931 you restore that functionality in expert plugin. Option to hide this THING can be also put there - since message structure also can be used to change html/text parts.
Comment 11 Matthias 2019-09-12 15:07:30 UTC
Now as this is a popular vote, what is happening?
Comment 12 Christophe Marin 2019-09-22 11:04:42 UTC
*** Bug 412190 has been marked as a duplicate of this bug. ***
Comment 13 Christophe Marin 2019-09-22 11:05:40 UTC
See https://phabricator.kde.org/M155 for the first mockups
Comment 14 null 2020-04-09 15:18:14 UTC
See [1] for a workaround in the meantime, i.e. you can apply a stylesheet to KMail to hide the bar. Compared to only changing colors (see Comment 5) this takes up less space on the left.

Note that you can still add a button to the toolbar for switching to HTML manually (although this does not work in the opposite direction, as documented in Bug 375314).

IDEA: Currently that toolbar button does not show whether an HTML part is available. Maybe setting the enabled/disabled state appropriately could be implemented, since the HTML bar already has code to distinguish between "No HTML Message [available]" and "Plain Message [, HTML available]".

[1] https://reddit.com/r/kde/comments/do27td/a_cure_for_kmail_html_message_status_bar/
Comment 15 Niko sagiadinos 2020-04-19 18:58:41 UTC
+1

This bar is annoying and ugly. 

The user should be allowed to decide whether to display an element and not be patronized like a small child. ;-)
Comment 16 Christoph Feck 2020-05-23 07:52:23 UTC
*** Bug 421936 has been marked as a duplicate of this bug. ***
Comment 17 bugzy 2021-07-09 16:00:19 UTC
This is now over two years since this issue has been reported, extensively commented on (https://bugs.kde.org/show_bug.cgi?id=393421 and https://www.reddit.com/r/kde/comments/do27td/a_cure_for_kmail_html_message_status_bar/), and had an alternative design proposed (See https://phabricator.kde.org/M155). It would be nice if this issue got some fresh attention either to revert https://phabricator.kde.org/R94:1c55919a64491bd5598cf9d8616e77b037edbf87 or move in the direction of the proposal listed above.