Summary: | Misc bugs in the composer due to KRichTextEdit | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | Thomas Zander <zander> |
Component: | composer | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | finex, steveire |
Priority: | NOR | ||
Version: | SVN trunk (KDE 4) | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Thomas Zander
2008-06-03 11:55:17 UTC
I confirm the first and the third problem on the krichtextedit. I've wrongly read the third "problem". I don't confirm it: what should happen with CTRL+SHIFT+UP/DOWN ???? Meanwhile I've created bug #163128 for the first problem. FiNeX; the bug is really that a widget that was written ages ago is still being used while most of the functionality it adds has been added to Qt / KDE already in the classes it inherits from. So my question is if we should bother maintaining the component or refactor. Especially since the component it inherits from does not have these problems. ps. the 3rd problem is a change from kmail1.9, its not too important. Ok Thomas. Using a widget instead of another is one problem. I've opened the bug #163128 simply for reporting that the krichtextedit widget has a problem. I didn't know about QTextEdit. If QTextEdit is better than krichtextedit, well, it should be used in place of krichtextedit. Not only in kmail, but even in other apps (it's used in korganizer for example). Finally, if all krichtextedit will be replaced with QTextEdit, krichtextedit should be removed for avoiding that developers still use it on new applications. Mantaining old code which do thing already done by the framework is not a good idea. > If QTextEdit is better than krichtextedit, well, it should be used in place of krichtextedit.
The whole reason that ktextedit + krichtextedit is used instead of qtextedit it that those provide support for spellchecking, search & replace, and, of course, rich text editing. And no, these things are not available in qtextedit.
Anyway, this bug might as well be in KMeditor or in KMail, I think both reimplement event handling and drag&drop as well.
CCIng Steve, I hope you don't mind. Not sure where the problem is exactly.
Confirmed 1). 2 (the double delete on backspace) is a KTextEdit regression, I think dfaure already has fixed it recently (same bug as the double-paste bug I think) The krichtext{widget,edit} is not old old, but new code mainly written to save developers the hassle of creating actions for rich text effects in each application separately. I can also confirm (1) on the krichtexteditor in kdeui/tests, so this is a krichtextedit bug. It's a side-effect of the way I implemented format painting in the widget. I suspect I'll need to handle another event or two in the widget, but I'll look into it by the weekend. What effect should ctrl-shift-up/down have? I tried it on qt-copy/demos/textedit, and it didn't seem to have any effect, so QTextEdit doesn't seem to have the feature either. Thanks, Steve. SVN commit 818348 by skelly: Remove the selectionFinished signal from the KRichTextEdit. It had been used as part of implementing text format painting. Now that is implemented in the mouseReleaseEvent of the KRichTextWidget. BUG: 163128 BUG: 163124 M +0 -6 krichtextedit.cpp M +0 -6 krichtextedit.h M +11 -13 krichtextwidget.cpp M +8 -1 krichtextwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=818348 |