Version: 1.7 (using KDE KDE 3.3.0) Installed from: SuSE RPMs Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB By default, the HTML formatting option shows disabled in the menu (as it should be), but it is in fact enabled. Not only is this confusing, it also means that in practice users will have HTML formatting ON by default. The bug goes away after changing the option once.
I can confirm this bug with the development version of KMail.
Ok I can confirm the problem now also. I don't think there is any chance of KMail accidentally sending HTML mail, I wouldn't be alarmed about that. I'm working on it.
CVS commit by sanders: Fix an html editing bug. Don't show the html toolbar by default after KMail has started up, this is actually a change in default settings. (Not sure it this should be backported/discussed). Remember the state of the html toolbar (as per usual in the settings, in the case of multiple composers last closed composer wins), and restore the html toolbar state when a new composer window is shown. Bug fix, keep the "Formatting (HTML)" checkbox menu item in the composer in sync with the visibility of the html toolbar. Keep the logic that resists sending plain text emails as html. That is even when html formatting is on and the html toolbar is shown an email won't actually be sent as html unless an html toolbar widget is actually used. CCMAIL:87742-done@bugs.kde.org M +15 -3 kmcomposewin.cpp 1.853 M +3 -1 kmcomposewin.h 1.253 --- kdepim/kmail/kmcomposewin.h #1.252:1.253 @@ -357,4 +357,5 @@ public: bool subjectTextWasSpellChecked() const { return mSubjectTextWasSpellChecked; } public slots: + void polish(); /** * Actions: @@ -743,5 +744,4 @@ protected: long mShowHeaders; QString mExtEditor; - bool mUseHTMLEditor; bool mUseExtEditor; QPtrList<_StringPair> mCustHeaders; @@ -752,4 +752,6 @@ protected: int mWordWrap; bool mUseFixedFont; + bool mUseHTMLEditor; + bool mHtmlMarkup; QFont mBodyFont, mFixedFont; // QList<QLineEdit> mEdtList; --- kdepim/kmail/kmcomposewin.cpp #1.852:1.853 @@ -504,4 +504,5 @@ void KMComposeWin::readConfig(void) mEdtCc->setCompletionMode( (KGlobalSettings::Completion) mode ); mEdtBcc->setCompletionMode( (KGlobalSettings::Completion) mode ); + mHtmlMarkup = config->readBoolEntry("html-markup", false); readColorConfig(); @@ -617,4 +618,5 @@ void KMComposeWin::writeConfig(void) config->writeEntry("transport-history", mTransportHistory ); config->writeEntry("use-fixed-font", mUseFixedFont ); + config->writeEntry("html-markup", mHtmlMarkup); } @@ -1038,5 +1040,4 @@ void KMComposeWin::setupActions(void) SLOT(slotToggleMarkup()), actionCollection(), "html"); - markupAction->setChecked(mUseHTMLEditor); mAllFieldsAction = new KToggleAction (i18n("&All Fields"), 0, this, @@ -3220,4 +3220,5 @@ void KMComposeWin::slotToggleMarkup() { if ( markupAction->isChecked() ) { + mHtmlMarkup = true; toolBar("htmlToolBar")->show(); // markup will be toggled as soon as markup is actually used @@ -3237,5 +3238,6 @@ void KMComposeWin::toggleMarkup(bool mar if ( !mUseHTMLEditor ) { kdDebug(5006) << "setting RichText editor" << endl; - mUseHTMLEditor = true; // set it directly to true. setColor hits another toggleMarkup + mUseHTMLEditor = true; + mHtmlMarkup = true; // set it directly to true. setColor hits another toggleMarkup // set all highlighted text caused by spelling back to black @@ -3257,4 +3259,5 @@ void KMComposeWin::toggleMarkup(bool mar else if ( mUseHTMLEditor ) { kdDebug(5006) << "setting PlainText editor" << endl; + mHtmlMarkup = false; mUseHTMLEditor = false; mEditor->setTextFormat(Qt::PlainText); @@ -3268,4 +3271,5 @@ void KMComposeWin::toggleMarkup(bool mar else if ( !markup && !mUseHTMLEditor ) { + mHtmlMarkup = false; toolBar("htmlToolBar")->hide(); } @@ -3297,4 +3301,12 @@ void KMComposeWin::slotSpellcheck() } +void KMComposeWin::polish() +{ + markupAction->setChecked(mHtmlMarkup); + if (mHtmlMarkup) + toolBar("htmlToolBar")->show(); + else + toolBar("htmlToolBar")->hide(); +} //-----------------------------------------------------------------------------
Still present in KDE 3.3.1. I just upgraded from KDE 3.2.3. When I first ran Kmail, the HTML option was NOT checked (which is correct), but the HTML toolbar was on (which is incorrect). Maybe it's fixed in HEAD and not backported? In this case, shouldn't it be?
On Wednesday 13 October 2004 20:04 pm, Jorge Adriano wrote: > Maybe it's fixed in HEAD and not backported? Yes, it isn't backported.
> > Maybe it's fixed in HEAD and not backported? > Yes, it isn't backported. Right, should I close the bug report again then? I wish it was backported though, it was reported and fixed right after 3.0, so I guess it shouldn't be that hard (?). J.A.
*** Bug has been marked as fixed ***.
Am Wednesday 27 October 2004 09:17 schrieb Don Sanders: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=87742 > sanders kde org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REOPENED |RESOLVED > Resolution| |FIXED > > > > ------- Additional Comments From sanders kde org 2004-10-27 09:17 ------- > *** Bug has been marked as fixed ***. So did you backport it meanwhile? I can't find a commit of yours in the 3_3_BRANCH Greetings, Stephan
No I did not backport. I consider backporting to be a wish rather than bug. If the bug is reopened then could the re-opener please reopen it as a wish. Thanks, Don.
> No I did not backport. I consider backporting to be a wish rather than bug. > If the bug is reopened then could the re-opener please reopen it as a wish. Hi, I don't think I can change it from bug to wish. Should I open a separate wish report asking for this bugfix to be backported then? J.A.