SUMMARY At some point in the past the default format for emails composed in kmail has changed to HTML, and I can NOT find any place to switch the default STEPS TO REPRODUCE 1. Open kmail preferences 2. Look at every single page in the settings dialog at least 15 times 3. Notice that there is no place to configure a default format for outgoing mails. There is one for displaying mails, though - just not for composing. OBSERVED RESULT See 3. above EXPECTED RESULT I would expect to find a checkbox on the "Editor preferences" page, or on the "create mails" page in the security area, to set the default for new mails to either HTML or plaintext. SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.1 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.1 Kernel Version: 4.12.14-lp151.28.48-default OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4771 CPU @ 3.50GHz Memory: 31,4 GiB ADDITIONAL INFORMATION
toolbar->rich text button" => uncheck it. For next email it will use plain text.
unless you have HTML in your signature, in which case it goes quietly back to HTML. The setting should be remembered on a per identity basis, at least.
if you have a html signature for sure it will switch to html.
(In reply to Laurent Montel from comment #3) > if you have a html signature for sure it will switch to html. Exactly, and that's how it should be. However, currently this does not work for the opposite direction: If there is a signature without HTML, KMail will not switch back to plaintext. HTML signature state can be configured per identity. If you have identity A with an HTML signature and identity B with a plain text signature, after using A KMail will behave as if it was set to rich text editing for B too. It would be more pleasant and more efficient for users if KMail switched back to plain text automatically in this specific case. Remembering rich text editing state per identity instead of globally sounds like a good idea. Whether or not this needs a checkbox in the identity settings dialog is a different question.
(In reply to xchain from comment #4) > Remembering rich text editing state per identity instead of globally sounds > like a good idea. that. > Whether or not this needs a checkbox in the identity settings dialog is a > different question. if it works reliably it would not need a checkbox at all...
"However, currently this does not work for the opposite direction: If there is a signature without HTML, KMail will not switch back to plaintext." So you have 3 identities, => first plaintext, second html, third plaintext you start to compose with default identity => the first => plaintext you decide to change to second => html => no problem it will switch you continue to write as html you change to plaintext identity => it will ask you if you want to lose html format. Each time that you will switch identity it will ask you.. Not sure that the user will be happy for it. If you decide to write an html mail and you switch to identity plaintext it will ask you if you want to switch to html. No sure it's very useful in this case no ?
> Each time that you will switch identity it will ask you.. If only the signature changes back to plain text (e.g. when you did not write any rich text above the signature yet), it's probably not needed to ask the user for confirmation and simply switch to plain text. Also, if the user already wrote some rich text in the current mail it is probably enough to assume that switching back to plain text is unwanted. In other cases asking for confirmation just like when using the rich text button directly might be needed, though. > So you have 3 identities That being said, there is also the (more common?) case of opening the composer already set to the correct identity automatically without having to switch manually (e.g. due to replying to a specific mail, or due to starting a new message from a folder with an associated identity): Having the correct rich text setting set by KMail instead of using the (global) recent one would be useful for sure. As long as users can override what KMail did automatically, I think there should be nothing wrong with this.
Here is an alternative idea, which is maybe a bit simpler and more in line with what users already know in terms of UI: You can already set a "Message Default Format" (i.e. HTML, plain text, or global) for each folder. Currently this applies only to viewing mails, but perhaps this could be replicated (as a separate setting?) for editing of mails. Since often a folder is used with only a single identity, this would achieve a similar effect. This would not help when all mail goes to a single inbox, of course, and requires a bit more effort to set up. The question is: Is rich text editing a property of identities, folders, or even individual contacts? Closely aligning with what KMail already supports in terms of HTML view settings might be a wise choice. Mathias: It is always helpful to include use cases and context in a bug, i.e. what is it you are actually trying to achieve? "Unable to configure X" is not an end in itself...
indeed user case can be useful. If we had too many settings user will not know where he must change settings. More easy is adding a global settings Adding this settings in each folder can be a pain for end user which will not knowning where it's configurated when they change it by error. I added a lot of bug report about identity where user changed it in specific folder by error and didn't know why they didn"t have a specific identity when they replied to an email.
wait info
(In reply to Laurent Montel from comment #10) > wait info what info and from whom?
(In reply to Mathias Homann from comment #11) > (In reply to Laurent Montel from comment #10) > > wait info > > what info and from whom? From you about "indeed user case can be useful."
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
user case: USer is using kmail for a work account and a private account, where the company policy dictates use of HTML in the .signature, but the user has plaintext inb the signature for his private account. now imagine these steps: - user sends a mail from his private account, switches to plaintext as the mail format - after this, user sends email from his work account, which due to the html signature hard enforces html format no matter what has been configured for the recipient in the contact entry - after this, user has to manually switch back to plaintext the next time he sends mail from the private account again. Can this be handled more intuitively? With less hassle for the user?