[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ktexteditor-devel
Subject:    Re: Access to the currently displayed document range
From:       Dominik Haumann <dhdev () gmx ! de>
Date:       2008-03-26 20:08:44
Message-ID: 200803262108.47728.dhdev () gmx ! de
[Download RAW message or body]

Hi,

On Wednesday 26 March 2008, Michel Ludwig wrote:
> Hi again,
>
> I'm currently implementing on-the-fly spell checking in Kile, and I've
> come to a point where it actually works, but things tend to slow in large
> documents. For example, one document has over 6000 SmartRanges installed
> on it after the spell checking and it is really painful to do some
> editing then.
>
> So, I've been looking for a way to restrict the number of SmartRanges
> that need to be installed on a document at a specific moment in time, but
> I couldn't find a way to actually get the currently displayed document
> range. Hence, I propose a new interface again :-)
>
> The attached "VisibilityInterface" (I don't like the name too much) adds
> a signal that notifies listeners of changes to the visible document
> range, and the method " getDisplayedRange()" is added which returns the
> currently displayed range.

1. We just discussed this on IRC and came to the conclusions:
- rename DisplayInterface to ViewportInterface
- rename getDisplayedRange to displayRange
- rename displayedRangeChanged to displayRangeChanged
- change Q_SIGNALS to public, as the class does not inherit QObject
  (see variableinterface.h for an example)
- add documentation that also states that the columns are of importance,
  think of dynamically wrapped lines
- the range returned by displayRange() is a object and no pointer, which
  was a typo in the first place

If I missed anything, please add it :)


2. With this, we add a new interface. Do you have ideas what other functions
  should/could go into the ViewportInterface? If there are other functions,
  we should do that in one go. ...otherwise there will be yet another
  interface.


3. With the above change, we also thought about the already existing signals
  KTE::View::horizontalScrollPositionChanged
  KTE::View::verticalScrollPositionChanged
Question is whether they are still needed (or needed at all): 
- Are there use cases where displayedRangeChanged is not enough with
  regard to verticalScrollPositionChanged?
  If not, verticalScrollPositionChanged should be marked as \deprecated for
  KDE5 and the ViewportInterface should be merged into KTE::View.

- Is horizontalScrollPositionChanged needed at all? displayedRangeChanged
  does NOT tell you about this. But I wonder whether anyone uses this
  signal. If not, it should be marked as \deprecated, too.

Thanks,
Dominik
_______________________________________________
KTextEditor-Devel mailing list
KTextEditor-Devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel
[prev in list] [next in list] [prev in thread] [next in thread]