Version: (using Devel) Installed from: Compiled sources KMail (kde4) uses a widget for the composer window that has various very weird interaction behaviors. (I'll list some below). I was wondering if the QTextEdit could not be used directly to use the standard behaviors. If this is not sufficient, what needs to be possible to make that happen. Problems I found include; * selecting by dragging the mouse is odd. When I click somewhere and drag the mouse to *outside* the widget where I release the button and I then move the mouse back into the widget the selection is altered after the mouse-release. * Using ctrl-backspace deletes 2 words. * ctrl-shift-up/down doesn't have any effect.
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