| Summary: | No ability to hide the HTML Message Status Bar | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Cristian Adam <cristian.adam> |
| Component: | UI | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | CLOSED INTENTIONAL | ||
| Severity: | normal | CC: | brent, brokencanoe, bugs.kde.attila, bugs.kde.org, bugzylittle, dm.vl.ivanov, edson, eridanired123, f.alexander.wilms, friiduh, hannibal, ict, iscy, ismelhaus, itumaykin+kde, jani-matti.hatinen, jjm, jsardid, kde, kdebugs, kdeu, keplicz, mail, Martin, matthijstijink, montel, nate, niels, null, peter, pieterkristensen, postix, pqztxb, shakerbg, ssliackus, styvn, sudhir, whatifgodwasoneofus, yuzyk, zebob.m |
| Priority: | HI | ||
| Version: | 5.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=399245 https://bugs.kde.org/show_bug.cgi?id=464213 |
||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
KMail HTML Status Bar
Alternate UI for the distracting and intrusive html bar html white bar |
||
+1 you can't to disable it as new user didn't know this feature. So now it's by default. Regards What do you mean by "you can't to disable it as new user didn't know this feature." ? As a user I don't need to switch between HTML and plain-text. I really do care about the vertical space used by the bar, so I need that bar gone. I don't think is too much to ask to have this user configurable in the settings. Kmail is growing into a real quality application that looks good too. But now the beautiful looks are being hit by this html-status-bar that makes a lot of noise about (in my opinion) not so much. If someone finds the message of the bar important that's ok. But I find it more important that kmail is comforting to the eyes. And is is! I would very much appreciate to have the opportunity to not see this laud bar. I have found a partial workaround – namely changing the background color of the HTML Status Bar. This can be done in Settings -> Configure KMail -> Appearance -> Colors. I have used "#fcfcfc" for all four "HTML Status Bar" entries. Not the status bar is still eating valuable screen width, but at least is not an eye sore anymore. I actually like the bar and its functionality. Not that my preference addresses the issue, but I am wondering if the toggle switch to turn off the bar at "Settings > Configure Kmail > Appearance > General > Show HTML Side Bar" has been removed. If not, simply turn it off. The setting ("Settings > Configure Kmail > Appearance > General > Show HTML Side Bar") has been removed in KMail 5.8.0 :(
The commit which removed the setting: https://phabricator.kde.org/R94:1c55919a64491bd5598cf9d8616e77b037edbf87 In my opinion this needs to be reverted. I wish I could remove this status bar too. I find this information completely irrelevant and distracting. This is horrible design, and the offered 'justification' for it is a sad, sad joke. At least give us a configuration option we can add to kmail2rc. If you're worried that new users won't be able to switch between HTML and non-HTML message views (a feature, which no one uses btw) make the HTML status bar visible by default and add a comment to the configuration page about the lost functionality if the bar is disabled. Simply forcing the bar on all users does absolutely nothing to promote said functionality. 99,5% of Kmail users are old users. Quit messing around with their settings. We've set it up the way we like it, and we know what we've done and why. *** Bug 393473 has been marked as a duplicate of this bug. *** Is there any way to re-open this issue. Whereas it is understandable that some kmail devs may want the html bar displayed by default in emails, there seems to be no real justification, or at least a satisfactory one, for removing the ability to change that default behavior. Note: I speak as one who uses and likes the html bar feature. I just don't think that it was reasonable to remove the ability to customize kmail, especially when there was no development cost that we know of(i.e. option that was already in place). *** Bug 393595 has been marked as a duplicate of this bug. *** I strongly agree with comments above > I think that this functionality might be required for some in their daily usage of the software. However, I find it quite annoying visually and liked the ability we had in previous versions to remove this bar in the Settings. Please, put it back. Thank you for your awesome job. Kmail is a really great piece of software ! :) @Laurent Montel: a new user wouldn't know about any option in the setting dialog. Your explanation makes no sense: should kmail disable any feature a new user doesn't know about. This is a regression bug not a new feature: the setting use to be in the Settings dialog and now it's not. Why would this bug be closed as wont'f fix. What is not possible to fix or doesn't require a fix ? I too can't understand why this happened. To me it is a strange choice. In my eyes there are a few (not much anymore) items to fix in kmail and this is NOT one of them. But still, you come a long end with the workaround from commend 5 that Christian Adams made: "I have found a partial workaround – namely changing the background color of the HTML Status Bar. This can be done in Settings -> Configure KMail -> Appearance -> Colors. I have used "#fcfcfc" for all four "HTML Status Bar" entries." You can make this ugly black disappear. Please, return this option. I don't want HTML message status bar... Also affected by this bug. Please revert the removal of the setting (https://phabricator.kde.org/R94:1c55919a64491bd5598cf9d8616e77b037edbf87) Just a very humble note to remember, that not everyone has not only the same point of view bat even the same abilities. E.g. my son is handicapped. He has impaired sight but additionally needs to have the things more simple to understand it. Kmail is actually the only mail client, which was possible to customize for his need. Yes, Kmail won in totally different field, than one could expected. It could be customized to be very simple, with big letters and big icons with best ratio between ability to see context and size of letters and icons. For me it always was a SW, which, if needed and if one is willing to spend many hours, is able to be customized in totally unique level. And this is absolutely different approach than the famous "we know perfectly what is the best for users, so we do that regardless the user want it or not" :-) . So the point of my note is, if it's really necessary to leave an area with unique position of the product. Btw. thanks my son's special needs, I discovered Linux years ago and we all switched to it as well. So back to Kmail. We can sure live with the html "something", but reading the discussion, I have a fear, that something has changed in the general approach and after next few changes like that, it becomes already unusable for us. And it would be very sad. Please restore the ability to hide this ugliness. This bar is visually irritating. Also rationale behind the change is wrong: https://github.com/KDE/messagelib/commit/1c55919a64491bd5598cf9d8616e77b037edbf87 "We don't have other method as statusbarhtml for switching mode for the moment" 1. There's a shortcut to toggle HTML view. 2. There's a button that can be added to a toolbar to toggle HTML view. *** Bug 393473 has been marked as a duplicate of this bug. *** Arbitrarily just changing this setting for users isn't the best experience. More so that i spent hours looking for ways to disable it as I usually do, only to find that option now disabled. While I appreciate all the work developers do on Kmail, - I think we're old enough to make our own decisions on what level of hand-holding we need in this area. There are enough markers and warnings as it is without another one staring us in the face. Dear Canoe (of comment 23). I applied the workaround of Christian Adam in comment 5. For the two foreground-items I choose the darker grey #7c7c7c and for the background items I choose the lighter grey #c0c0c0. It looks even cozy that way. But I am under the impression that we are protected against our selves and I don't like to be treated that way. To me that is un-kde-isch... (In reply to Laurent Montel from comment #2) > you can't to disable it as new user didn't know this feature. > So now it's by default. > Regards There was no reason to remove this option for users. Put it back. We didn't come to KDE to be treated like we don't know better, we already have GNOME maintainer for that. Please use a discrete icon, or go back to the menu setting, or a toggle in the menu bar, or all three... but not a hideous line which should have stayed in the 1990s, which a user may not need and can't turn off, and which distracts Users and is thus bad for workflow (not to mention wasted time trying to figure out how to make it disappear!) This forced feature brings no benefit to me. I have already decided to use HTML and to load external resources by default. KMail should honor my decision. It's distracting and ugly. Please bring back the ability to disable this feature. It has been four months already. How hard is for a KDE developer to revert a commit, review it, and merge it? Is "Laurent Montel" the only developer who works on KMail? If somebody does the revert today, it will take months (years?) until the distros get the fix. This is crazy! KMail 5.8.3 now, I have to add my vote that this is annoying, even with Cristian's work-around. Please, Laurent! :) KMail 5.8.3 now, I have to add my vote that this is annoying, even with Cristian's work-around. Please, Laurent! :) This commit should definitely be reverted. Not only it removes a setting that we are used to set, it creates a flicker on the message pane. Whenever I switch folder, the bar disappears and it seems to appear again only once the content is displayed. So, the text in the email jump left then right every time I switch folder. In order to have a working Kmail again, I've reverted the patch and rebuild the latest FC28 RPMs. The message lib is freely available here: https://services.spectrumdt.com/RPMS/messagelib/ No bump in version were executed, so if you are running FC28, simply ensure that you have the latest version and then reinstall that RPM. # dnf update messagelib # rpm -vh --reinstall kf5-messagelib-18.04.3-1.fc28.x86_64.rpm Please return this option. What is the benefit of this HTML Message bar? I don't get it. It is annoying and it's all the time in the middle of the screen. As already mentioned earlier, this is intentional. (In reply to Christophe Giboudeaux from comment #33) > As already mentioned earlier, this is intentional. The fact that it is intentional does not address the issue of this bug report, which is that functionality that users really want has been removed. My impression is that there is a push in the KMail development team to simplify the settings. That may be needed, but there are ways to avoid removing functionality at the same time. Namely, as was done for Bug 387931, the setting for this can for example be added to the Expert plugin. From the commit message I understand that this is a transitional situation (“I will look at how I can change this feature in the future”). The response to this bug report has made it clear that during the transitional period it is preferable to still have this feature. So please revert or add to the Expert plugin. (FYI: I personally like and use the HTML bar.) Created attachment 115264 [details]
Alternate UI for the distracting and intrusive html bar
Is it necessary to keep it absolutely ugly and intrusive? Could we not come up with a UI that is less distracting to the users. Take for example, it can be shown at the top like the external resources message is shown which is less intrusive. Please see the screenshot attached.
(In reply to Sudhir Khanger from comment #35) > Is it necessary to keep it absolutely ugly and intrusive? Could we not come > up with a UI that is less distracting to the users. Take for example, it can > be shown at the top like the external resources message is shown which is > less intrusive. Please see the screenshot attached. This bug is about the option to hide the HTML bar, which has existed for a long time and is used and liked by many (and not by many others). This is not the place to discuss alternative UI proposals. Please keep on topic. (In reply to Christophe Giboudeaux from comment #33) > As already mentioned earlier, this is intentional. Being intentional doesn't mean it's a good idea. It isn't, as the flood of comments here shows. What other development team ignores its users? Open source... Part of the KDE family... Not: 'I'm the maintainer, therefore we can ignore all Users without any rational reason'. It raises the question, who gets to decide here? It would be a shame to have to fork this software over one ridiculous and irrational design choice, but if a decision like this rests in just one pair of hands and no-one can have any influence, than fair enough - I guess that's the end result, it also explains so many other opensource software splits in the past. You can have usability AND customisation, by intelligent defaults, combined with advanced settings with certain users. However, this decision renders Kmail neither usable nor customisable. No other software makes the casual user have to face an ugly distraction on every email, with no way of turning it off. Advanced setting removed. Because the Users can't be trusted to know their own needs and take their own risks? And no better way of presenting the option than a block line across every email. Ouch. Yes, it doesn't make any sense (this is just my opinion -- a user that agrees on 99.9% of KDE dev decisions, but not this one). This reminds me plasma cashew, btw... +1 for removing HTML-view feedback (aka the bar, vignet). I think users understand their own preferences without it. (In reply to Erik Quaeghebeur from comment #36) > (In reply to Sudhir Khanger from comment #35) > > Is it necessary to keep it absolutely ugly and intrusive? Could we not come > > up with a UI that is less distracting to the users. Take for example, it can > > be shown at the top like the external resources message is shown which is > > less intrusive. Please see the screenshot attached. > This bug is about the option to hide the HTML bar, which has existed for a > long time and is used and liked by many (and not by many others). This is > not the place to discuss alternative UI proposals. Please keep on topic. And where is the right place to discuss alternative UI proposals ? There was no discussion when the feature was removed. (In reply to pqz from comment #41) > And where is the right place to discuss alternative UI proposals ? Another bug report (as feature request), kdepim-devel mailing list, KDE forums. > There was no discussion when the feature was removed. Not with users, indeed, and that is one of the reasons this bug report is so ‘popular’. (In reply to Christophe Giboudeaux from comment #33) > As already mentioned earlier, this is intentional. Wouldn't be more simple to change the type of this ticket (to feature request) instead of opening another one ? Closing with the explanation that was given seem a bit rude to me. (In reply to Christophe Giboudeaux from comment #33) > As already mentioned earlier, this is intentional. Wouldn't be more simple to change the type of this ticket (to feature request) instead of opening another one ? Closing with the explanation that was given seem a bit rude to me. *** Bug 393595 has been marked as a duplicate of this bug. *** (In reply to Erik Quaeghebeur from comment #42) > Another bug report (as feature request), kdepim-devel mailing list, KDE Here it is: bug 399245 as a feature request (In reply to Cristian Adam from comment #5) > I have found a partial workaround – namely changing the background color of > the HTML Status Bar. > > This can be done in Settings -> Configure KMail -> Appearance -> Colors. I > have used "#fcfcfc" for all four "HTML Status Bar" entries. > > Not the status bar is still eating valuable screen width, but at least is > not an eye sore anymore. This workaround only works for Kmail launched as a single application. It has not effect if Kmail is embedded in Kontact. Not that I wanted to remove it completely but I wanted a more integrated background in white with nice text in soft blue (breeze like). But no way to do this :( (In reply to avlas from comment #47) > (In reply to Cristian Adam from comment #5) > > I have found a partial workaround – namely changing the background color of > > the HTML Status Bar. > > > > This can be done in Settings -> Configure KMail -> Appearance -> Colors. I > > have used "#fcfcfc" for all four "HTML Status Bar" entries. > > > > Not the status bar is still eating valuable screen width, but at least is > > not an eye sore anymore. > > This workaround only works for Kmail launched as a single application. It > has not effect if Kmail is embedded in Kontact. > > Not that I wanted to remove it completely but I wanted a more integrated > background in white with nice text in soft blue (breeze like). But no way to > do this :( There is actually a way to do this, but it's far from obvious, as one needs to apply this in kmail settings and then copy that section to kontact settings manually... No need to say that this should be applied directly withouth having to: 1. Open kmail as a standalone application 2. Change the settings 3. Open kmailrc and copy the relevant section 4. Edit kontactrc by pasting that settings section @avlas thanks for that info. By any chance do you have the code that is relevant for removing this egregious UI. (In reply to Sudhir Khanger from comment #49) > @avlas thanks for that info. By any chance do you have the code that is > relevant for removing this egregious UI. Sorry, perhaps I was not clear enough. These config sections are not for disabling the html status bar, but for changing its appearance. These are my settings in the Reader section of kontactrc and kmail2rc: ColorbarBackgroundHTML=250,251,252 ColorbarBackgroundPlain=250,251,252 ColorbarForegroundHTML=0,116,185 ColorbarForegroundPlain=250,251,252 I configured it so that the background of the html status bar always matches the window background color (according to the color scheme you use), and for the text color, I set it to blue when HTML is active, and virtually invisible otherwise (by matching the color of the background in plain text emails). Created attachment 117651 [details]
html white bar
Even if you set the colors to either white or grayish you will end up with same bad UI behavior.
@avlas Where do I put ColorbarBackground code? Under some heading like [Reader] or just at the bottom.
[Reader]
CloseToQuotaColor=218,68,83
ColorbarBackgroundHTML=255,255,255
ColorbarBackgroundPlain=255,255,255
ColorbarForegroundHTML=255,255,255
ColorbarForegroundPlain=255,255,255
LinkColor=41,128,185
QuotedText1=32,145,80
QuotedText2=26,116,64
QuotedText3=19,87,48
ScamDetectionEnabled=false
attachment-strategy=inlined
defaultColors=false
header-plugin-style-name=brief
htmlLoadExternal=true
htmlMail=true
showColorBar=false
(In reply to Sudhir Khanger from comment #51) > Created attachment 117651 [details] > html white bar > > Even if you set the colors to either white or grayish you will end up with > same bad UI behavior. > > @avlas Where do I put ColorbarBackground code? Under some heading like > [Reader] or just at the bottom. > > [Reader] > CloseToQuotaColor=218,68,83 > ColorbarBackgroundHTML=255,255,255 > ColorbarBackgroundPlain=255,255,255 > ColorbarForegroundHTML=255,255,255 > ColorbarForegroundPlain=255,255,255 > LinkColor=41,128,185 > QuotedText1=32,145,80 > QuotedText2=26,116,64 > QuotedText3=19,87,48 > ScamDetectionEnabled=false > attachment-strategy=inlined > defaultColors=false > header-plugin-style-name=brief > htmlLoadExternal=true > htmlMail=true > showColorBar=false Under [Reader] 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. What starts to puzzle me about this whole discussion is that no one ever took the trouble of explaining why this bar had to be fixed. Why so many faithful users had to be "kicked against the sore leg" as we say in my country. It seems to me that there must be a really simple and good explanation to take a measure that harsh that also ruins the looks of your application. What is this reason? Please explain. It is a security reason. You could receive an HTML mail that looks like a plain text mail, and with HTML you have the ability to embed malicious links everywhere. If you have no way to see that the message is actually an HTML message, i.e. _outside_ the message viewer, you could click those links without being aware that they link to sites that you don't see in the text. I agree, though, that there could be other possibilities to inform the user of HTML mails, e.g. via statusbar or toolbar icons. But if they are too non-obvious, you could miss them. In other words, if the security bar is in your face, it actually works as intended. Also, the message viewer doesn't know about other UI elements. If you find a different way that doesn't compromise security, please let us know. Patches to https://phabricator.kde.org/differential/diff/create/ I think most people don't object to real security. What people object to here is the following: - It's not clear how this thing actually generates any security. HTML emails are not commonly understood by the average user to be potentially insecure, so warning them than an HTML email is in fact an HTML email is not perceived as a warning of potential danger but rather as a pointless annoyance. - It can't be disabled at the user's preference. Risk is an everyday part of life, but there is no way for a knowledgeable or confident user to knowingly accept the risk of HTML emails in KMail they way they can knowingly accept the risk of driving a car, participating in sports, etc. It feels insulting when the software says, "you can't handle this risk". Imagine how infuriating it would be if your car told you "Warning! Driving a car is dangerous! Please drive safely!" every time you turned it on. - It's ugly. There are many ways to communicate this information in ways that are not so visually objectionable. Thunderbird uses a horizontal bar with a yellow background that looks much better, for example. Nate, I agree that the current solution looks quite out of place. There is the writing "no HTML message" black on white when the message just has no HTML part. There is the writing "clear text message" black on white, when it has one but the cleartext part is shown. There is the writing "HTML message" white on black when the HTML part is shown. And then there is a bug when switching from HTML part back to clear text part, it still display "HTML message" white on black. So first the choice of colors IMHO is just ugly. The colors do not blend well with Breeze Dark theme. The white on black "HTML message" bar totally looks out of place. Second it has three states, while for the user only one information is important: Is what is currently viewed HTML or is it not. With the option that when both clear text and HTML are available, that HTML status bar allows to toggle. In addition in my KMail configuration for security reason I do not even let it render HTML without my prior confirmation. Thus I have a box with red frame at the top of the mail with "Note: This is an HTML message. For security reasons, only the raw HTML code is shown. […]" giving me the option to enable HTML rendering in case I trust the sender. In case KMail is configured like this the vertical bar is completely superfluous. I believe with good user interface design it might be possible to merge both this box and the HTML status bar into one and make it less intrusive. Laurent, Christoph, I kindly ask you to reconsider and at ask for input from VDG team. And if on it, it might be good when VDG people look through the rest of the application as well. Thus I'd reopen the bug and set usability tag. (In reply to Christoph Feck from comment #55) > It is a security reason. You could receive an HTML mail that looks like a > plain text mail, and with HTML you have the ability to embed malicious links > everywhere. If you have no way to see that the message is actually an HTML > message, i.e. _outside_ the message viewer, you could click those links > without being aware that they link to sites that you don't see in the text. This is completely spurious. If you click on a link, you know it's a link. If it's a link it must be in HTML. You don't need an ugly great splodge to tell you it's HTML. If you think there are people who can't see this, let them keep the warning. The rest of us, who've used the Internet for more than five minutes, should be allowed to switch the splodge off, as we always used to be. (In reply to Peter Humphrey from comment #58) > (In reply to Christoph Feck from comment #55) > > It is a security reason. You could receive an HTML mail that looks like a > > plain text mail, and with HTML you have the ability to embed malicious links > > everywhere. If you have no way to see that the message is actually an HTML > > message, i.e. _outside_ the message viewer, you could click those links > > without being aware that they link to sites that you don't see in the text. > This is completely spurious. If you click on a link, you know it's a link. > If it's a link it must be in HTML. You don't need an ugly great splodge to > tell you it's HTML. > > If you think there are people who can't see this, let them keep the warning. > The rest of us, who've used the Internet for more than five minutes, should > be allowed to switch the splodge off, as we always used to be. Peter, KMail has clickable links also in plain text view. In HTML however the link can go to an entirely different location than what the user gets to see, while in plain text it cannot. Thus there is a valid security concern. (In reply to Martin Steigerwald from comment #59) > KMail has clickable links also in plain text view. In HTML however > the link can go to an entirely different location than what the user gets to > see, while in plain text it cannot. Thus there is a valid security concern. Ah, well in that case, maybe you've just shown the route to a solution: make sure that both views show the same, real value of the link. I can see there may be complications in doing that (different display engines being used) but this seems to be where the insecurity comes from - not from the user, who's unlikely to understand that the black bar is trying to warn him of the distinction you've drawn: what it says is nothing like what it seems to mean. I didn't see it anyway, in spite of having been using the Internet for a bit longer than five minutes. :) Is anything happening with this bug? There are many reactions. E.g. a father with a son who is visually handicapped and also the very respected Nate Graham took the time to explain why this html-bar is a mistake - and he explained very clear! I can only imagine that if he enters this discussion something must be very wrong! When are you reverting this change? Kmail is becoming a very good application. Stop messing it up! *** Bug 408727 has been marked as a duplicate of this bug. *** Is there maybe a fork of kmail that doesn't pander to the pathetic? Removing settings is patronising to new users and annoying to everyone else. As to the "security" justification, that is the user's responsibility if they choose to disable the bar and then blindly click on emails, not yours. At the very least make it a bit less 'in your face' - other email clients seem to manage without a big ugly vertical text thing there. (In reply to mail from comment #63) > Is there maybe a fork of kmail that doesn't pander to the pathetic? Maybe that would be a solution. Bugs like this are one of reasons I stopped reporting bugs against KDE. Surprised to find that we cannot disable the bar (anymore), but are still allowed to obfuscate it by changing its colors. This makes little sense, unless the goal is to have kmail's appearance be less attractive and inconsistent. (In reply to Niels from comment #66) > Surprised to find that we cannot disable the bar (anymore), but are still > allowed to obfuscate it by changing its colors. This makes little sense, > unless the goal is to have kmail's appearance be less attractive and > inconsistent. Maintainer knows best. Well, he thinks we shouldn't be allowed to assess our own risks. Arrogance personified. Just shrug and move on... > It is a security reason. You could receive an HTML mail that looks like a plain text mail, and with HTML you have the ability to embed malicious links everywhere. If you have no way to see that the message is actually an HTML message, i.e. _outside_ the message viewer, you could click those links without being aware that they link to sites that you don't see in the text.
I just assume that every message is an HTML message. Most of the time i am right.
I changed all the colors to black. It's what i call security by obscurity ;-)
I wonder when K9Mail authors are going to remove the ability to open links in your browser of choice and only allow wget piped into less because it's obviously more secure than GUI browsers.
This is still the wrong decision. You are taking away my responsibility for my own actions. It's hard to call a decision being wrong when you don't know the target group as well. There is a big target group of e.g. MS users, who loves app which decides most of the things instead of them. And if somebody come with a client which, using AI, will answer the emails, they will use it. But there are users, who don't like it. So my son suffered years for such decision done by MS, that the only one and suite for all size of icon is the one, they chosen. So we changed Win to Linux. For the same reason we start using Kmail but later on we recognized, that Kmail incorporated the same philosophy, so we stopped using Kmail. That's nothing wrong on it, which philosophy you choose. BUT what I would have been appreciated very much, if you would let us recognize this your philosophy before I spent so much time to adapting the UI for my son. note: I wouldn't call your decision wrong but for sure inconsistent with the strongest Kmail feature, i.e. extremely high configurability. And to be honest, I really can't imagine a target group profile for Kmail. My God, I hate this bar! I've gone all over Google trying to figure out how to remove it simply because I want to use the entire KDE ecosystem, but it's just annoying FWIW, there were some further discussions and mockups on https://phabricator.kde.org/M155 No further comments from my side as the discussions already brought up very good arguments for this issue. I have not used KMail for few years now. Just returned back to use it after using Gmail web interface for so long, and solely because after decade the wished features had been finally implemented (Ctrl+M to hide menus for new and message windows). I spent just over an hour to seek that where was the setting to hide that HTML bar. I knew that there is a setting to hide it, all I could find was all the new nice features like exceptions to download external data etc. IMHO email should be just about text. Any HTML email is nothing else than trouble and insult to every email user, same way as idea of top posting. After an hour I gave up and decided to just search for where the setting was. And I found this thread... So after few years, I decided to log-in to my old bugzilla account just to write this comment. I read almost all comments in this thread, and I am stunned that maintainer just say "As-Is" and "Closed Interntional". Those are not valid reasoning at all for closing this bug report. KDE was known for long time to be the most configurable and customizable by the user, to get it look as wanted. KMail had for long time the annoying forced way to require menubar be visible everywhere, denying to make a functional, easy and nice looking interface for email users. And now one step forward, one step backward... Gain something, lose something. This time it is just all the time on-your-face that there is some mystical HTML message or NO-HTML etc. Just confusing normal users and causing fear and worry. Not that there would be one time information or until user clicks "Don't show anymore", but it is forced to stay there all the time... |
Created attachment 112189 [details] KMail HTML Status Bar After upgrading to KMail 5.8 on KDE Neon I have noticed a back "HTML Message" vertical button bar in the middle of the screen. This is very distracting and it brings very little functionality. Almost all my email messages are HTML anyway. And if I click on it nothing happens in the email view panel. See the attached screen shot.