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