Bug 464213 - "html status bar" Place and view incostent to main configuration
Summary: "html status bar" Place and view incostent to main configuration
Status: REPORTED
Alias: None
Product: kmail2
Classification: Applications
Component: UI (show other bugs)
Version: 5.19.3
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-12 21:09 UTC by Schoerch
Modified: 2023-05-01 15:05 UTC (History)
2 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 Schoerch 2023-01-12 21:09:14 UTC
"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?