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