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

List:       kde-core-devel
Subject:    KTextEditor enhancement
From:       Christoph Cullmann <crossfire () babylon2k ! de>
Date:       2001-10-07 21:12:56
[Download RAW message or body]

Hi,
I would propose to enhance the KTextEditor stuff now ;) (or we will have the old \
trash in kde 3 too :(

I would say this:
- doc/view model should stay, seems to be a good way of managing textdocs/widgets
  (k, we can't use emacs than easily through such an interface, but we shouldn't drop \
the good doc/view stuff only because we wan'T  to be compatible with each editor on \
this world)

- there should be a queryInterface (QString name) function to allow progs to \
implement the interface even if they don't support all stuff  and to allow other \
progs to query what is supported  (hehe, right, stolen the idea from mhk's KEditor in \
gideon, but a bit other way of implementing it)

- I don't like the idea of spliting the interfaces in 1000s of classes (like in the \
keditor stuff in gideon, which is too big in my eyes),  I think of something like \
this:

  i.e. for the KTextEditor::View class something like this

  class View
  {
    virtual bool queryInterface (QString name) { return false; };

    // this stuff is in editInterface
    virtual void insertLine () = 0;
    virtual void killLine () = 0;

    // this is in undoInterface
    virtual void undo () = 0;
    virtual void redo () = 0;
  }

  If queryInterface says true for "editInterface", the prog which uses the part knows \
that the insert and kill stuff is implemented, if undoInterface is false  for example \
it knows, the current part doesn't implement the undo/redo stuff (the virtual \
functions aren't reimplemented there).  
  That way we archieve two goals at once:
  1. The implementor programs like Kate, KWrite .... must only implement \
                KTextEditor::View and Document (no 10 or more classes to implement, \
                if a
     editor is more powerful than just a textviewer). That easy use will attract more \
                programers to use it (and more: to use a clean doc/view model, or
     is our goal of integration just to start a extern editor app and say "open this \
file" and that was it ?).

  2. We have the chance to enhance the interface more and more, because old progs \
                simply would return false for unknown interfaces and needn't
     implement the new virtual functions (we won't break BC witch adding virtual \
stuff, or ?)

Hope some of the stuff I mentioned is at least interesting.
cu
Christoph


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