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

List:       ktexteditor-devel
Subject:    Re: Smart cursors, ranges and performance
From:       Hamish Rodda <rodda () kde ! org>
Date:       2005-06-25 10:26:53
Message-ID: 200506252026.55538.rodda () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sat, 25 Jun 2005 07:47 pm, Christoph Cullmann wrote:
> On Saturday 25 June 2005 11:35, Hamish Rodda wrote:
> > 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.
>
> I think I would prefer my way over the qobject hassle, but hey, not sure ;)

The more I think about it:
QObject: for UI type stuff like associating actions, showing contextual 
information in another widget, etc.
virtual inheritance: for parsers / syntax highlighters etc.

so, I've just gone ahead and implemented both :)  No extra cost if you don't 
use them (well, maybe you lose sizeof(pointer) * 2, heh).  Nice.

> > 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.
>
> I am not sure, as this is really a nice thing to have if you need in your
> code line and column as ints, otherwise stuff ends up to be very large or
> unefficient, like to fill 2 ints with cursor pos is now:
>
> int l,c;
> view->cursorPosition().position (l, c);
>
> otherwise this would be:
>
> int l (view->cursorPosition().line()), c (view->cursorPosition().column())
> (which is much more inefficient)
>
> or
> KTextEditor::Cursor tmp (view->cursorPosition());
> int l (tmp.line()), c (tmp.column())

I take your point, it can stay (I was just looking for cruft to delete)

> which is much more code, I really would like to have this stay, but btw., I
> would like to have all int line/column api be removed everywhere where it
> occurs as tuple and have the cursor used, like in the current
> KTextEditor::Range, not sure why we need setEnd (int, int), the people
> should use cursors ;)

Yeah, I agree.  The reason we have those convenience methods is for when the 
data is not coming from a cursor to start with, to save having to do 
setPosition(Cursor(line, column)) all the time.

kate4 is going to rock.

Cheers,
Hamish.

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]