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

List:       kwrite-devel
Subject:    Re: Smart cursors, ranges and performance
From:       Hamish Rodda <rodda () kde ! org>
Date:       2005-06-25 9:35:48
Message-ID: 200506251935.48228.rodda () kde ! org
[Download RAW message or body]

On Sat, 25 Jun 2005 07:13 pm, Christoph Cullmann wrote:
> On Saturday 25 June 2005 04:04, Hamish Rodda wrote:
> > I've decided for the sake of performance to do away with having these
> > classes be QObject subclasses, at least internally.  I feel the choices
> > are:
>
> fine ;) I wanted to remove the QObject inheritance since ever, but never
> got the time ;)

Yeah, it's not a small job... i'm going to do some other fundamental changes 
as well; it will hopefully be a much quicker system, with only those cursors 
needing to provide notification even being touched when they aren't on the 
same line as a change being made.

> > 1) Create a separate cursor and range classes for the interface, which
> > bind directly to the internal classes.
> > 2) Share the class directly out through the interface.
<snips>
>
> I think 2 is the much better thing, even if you have to inherit from them,
> still, this is least hassle.

The problem with 2 that I've realised is that for notifications to be 
available via subclassing, all of the implementation would have to be in 
ktexteditor, and to have hooks... not fun.

> btw., just out of fun, 3) alternative would be: provide some CursorFeedback
> interface, which the apps can subclass, and which they can pass to the
> constructor of the KTextEditor::SmartCursor, and which will let them get
> notifications, like
>
> CursorFeedback {
>    public:
>      void lineInserted (....);
> }
>
> But guess this is just the same as 2, beside that the cursor stuff needs
> not to be virtual, but this interface

Hmm, interesting... I have actually been working today at implementing a 
combination of 1 and 2, just creating an internal QObject when someone really 
wants to have notification via signals, and otherwise not creating a QObject.  
Your idea sounds quite good though.  I wonder which method would be the most 
preferred by the users... they're both easy with what I've designed.

Oh, I also wanted to know if there were any objections to removing functions 
which allow retrieval of values via non-const references or pointers, such as 
Cursor::position(int &_line, int &_column).  I think you get cleaner and more 
readable code if you use line(), column() etc. instead.

Cheers,
Hamish.
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]