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

List:       ktexteditor-devel
Subject:    Re: Smart cursors, ranges and performance
From:       Christoph Cullmann <cullmann () babylon2k ! de>
Date:       2005-06-26 19:11:47
Message-ID: 200506262111.50031 () cullmann
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 25 June 2005 12:26, Hamish Rodda wrote:
> 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.
k, I think I can live with this massive memory wasting, finally I have usage for my 2 gigs of ram ;)
no, serious: cool, this 2 punch tactic for different use cases sounds like sane idea, for visual feedback \
stuff,  the qobject creation time is really non-interesting, and for internal stuff which needs to be \
fast, where you eventually even can measure virtual function costs, the inheritance sounds like sane way \
;)

> I take your point, it can stay (I was just looking for cruft to delete)
> ) me too, first I had this removed, and than I tried to convert stuff and thought: bah, which hassle ;)

> 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.
yes, thought so, I first wanted to create such convenience methodes for the editing functions, too, but \
that would have blown up the interfaces size and killed any overview, we should minimize this to just few \
cases, guess ranges stuff could stay, as one can argue that ranges are just as low level as cursors, even \
if they use them internally, and that apps will feed them often with line/col tuples

> 
> kate4 is going to rock.
yes, we will have breakthroughs in all regions:
  - better internal structure (kate part)
  - MUCH better interfaces (for all ktexteditor parts)
  - MORE IMPORTANT: more easy API, with cursors, ranges and smart cursors ;)
    guess, this really makes ktexteditor to most powerful texteditor API around atm, given that
    emacs/vim provide nothing at all to embed them in real sane way or any useful public API and that \
                scintilla's API is kind of weired ;)
  - wider adoption of KTextEditor, with Kate using it now, too
  - more competition, with yzis as second implementation of our interfaces

looking forward to more improvements in the near future, thx for the cool work ;)

cu
Christoph

-- 
Christoph Cullmann
KDE Developer, kde.org Maintainance Team
http://www.babylon2k.de, cullmann@kde.org


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