D29318: [KPIMTextEdit/FindBar] Respect rich formatting and user settings when replacing all
Igor Poboiko
noreply at phabricator.kde.org
Fri May 1 14:14:01 BST 2020
poboiko added a comment.
In D29318#660961 <https://phabricator.kde.org/D29318#660961>, @dvratil wrote:
> If the code is shared, why not put it into a shared function that both editors can call? As fat as I can see, the function would only need the `QTextDocument` and the `mFindWidget` as inputs and would return the number of replacements made, which you can then use to emit the signal.
That's what I've tried to suggest originally:
> (in principle, to avoid code duplication, we can move this to FindBarBase. We only need to access mView->document(), which depends on the underlying text widget, so we could add a virtual QTextDocument *document() method to FindBarBase and reimplement it)
But now as I can see it might be not the best place: it would seem like `TextEditFindBarBase` is supposed to be as backend-agnostic as possible (not even necessary `QTextDocument`-based...). Do you have suggestions, where should I put it then?
Actually, there is a larger issue with that: the `RichTextEditFindBar` and `PlainTextEditFindBar` classes are completely equivalent (up to naming), not only the added method :(
(that stems from the fact that both `QTextEdit` and `QPlainTextEdit` have similar interface: we only use methods `document`, `textCursor`, `moveCursor`, `setTextCursor`, `isReadOnly`, `find`, and they are present in both classes).
REPOSITORY
R86 PIM: Text Editor
REVISION DETAIL
https://phabricator.kde.org/D29318
To: poboiko, mlaurent, dvratil
Cc: dvratil, kde-pim, fbampaloukas, dcaliste, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200501/d0a3951d/attachment.html>
More information about the kde-pim
mailing list