[kmail2] [Bug 464213] New: "html status bar" Place and view incostent to main configuration

[Schoerch]

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

            Bug ID: 464213
           Summary: "html status bar" Place and view incostent to  main
                    configuration
    Classification: Applications
           Product: kmail2
           Version: 5.19.3
          Platform: OpenSUSE
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: UI
          Assignee: kdepim-bugs at kde.org
          Reporter: joerg.buelow at schoerch.de
  Target Milestone: ---

"html status bar" place and visibility incostent to main configuration
***
I refer to BUG 393421. Please read carefully and try to be sensitive to the
understanding of this problem.

The skin problem is the location and behavior of the vertical status bar. The
second problem is the unnecessary and pointless display when in the Kmail
configuration only plaint text mails are allowed. This status bar is always
there, even if there is no mail at all. The basic logic is simply wrong.
***

STEPS TO REPRODUCE
1. configure: setup -> Security -> html messages -> all checkboxss unchecked
(aka meaning only plain text)
2. browse to empty folder 
3. the status bar is always visible

OBSERVED RESULT
The status bar is always visible (vertical).

EXPECTED RESULT
No status bar is visible.

LOGIC BEHAVIOR
The status bar must be removed there.

The status bar information belongs horizontally integrated into the header of
the currently displayed mail. Depending on the display:
a) Mail is only plain text -> invisible
b) Mail is text and html -> which view is active (click to change)
    initial view depend of default config settings plain text or html
c) Mail is html and has no plain text content -> warning in RED (not RFC
conform), which view is active (click to change)
   initial view depend of default config settings: plain text (rendering from
html and block all links) or html

All security concerns are solved with this logic and UI is more user friendly. 
The settings are then united to the UI. No pixels are wasted. And with this,
all user groups (even the power users, because they know what they are doing)
are satisfied.

ADDITONAL INFROMATION
I can understand both sides, but to persist in an outdated point of view makes
no sense. Why don't we bring the dissatisfied user groups from other mail eco
systems into our camp when this solution is implemented?

-- 
You are receiving this mail because:
You are the assignee for the bug.