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

List:       kde-devel
Subject:    Re: CORBA in mail clients (was Re: CORBA Book)
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-04-11 14:06:54
[Download RAW message or body]

Hi,

On Sat, 10 Apr 1999, Simon Hausmann wrote:

> 
> On Sat, 10 Apr 1999, Matt Koss wrote:
> 
> > On So, 10 apr 1999, Simon Hausmann wrote:
> > >On Fri, 9 Apr 1999, Rik Hemsley wrote:
> > >
> > >> Simon Hausmann wrote:
> > >> [...]
> > >> > But in regard to a componentificated text editor I suggest having a look
> > >> > at KWrite:
> > >> > - KWrite is based on the document view model (making adaptions to
> > >> >   OpenParts's document view model easier IMO)
> > >> > - is seems to be very good (!) documented
> > >> 
> > >> If KWrite had vi+emacs keys (perhaps it's already doing some emacs, I
> > >> don't use it), it would be ideal as an open part. I think most
> > >> developers probably use vim or emacs. Editors like NEdit, jed, joe etc
> > >> all have keybindings similar to emacs or to standard KDE keys anyway, I
> > >> believe.
> > >
> > >Beside key bindings ;-) I think another criteria for making a text editor
> > >component is: How would use it?
> > >
> > >Currently I see a forked codebase of KWrite :-(
> > >In the first place it is located at its correct place, in kdeutils/kwrite
> > >as full-fledged text editor. But then there are the kdevelop guys who
> > >(obviously) want a nice, highlighting-capable text editor, so they copied
> > >the files.
> > >This is, in my very humble opinion, a situation where re-usable components
> > >make sense.
> > >
> > >My idea would be:
> > >
> > >Create a general editor interface description and put it into a
> > >standardized location for common used interfaces. (I suggested
> > >kdelibs/corba/idl , but that's open for discussion ) . Then modify KWrite
> > >(and perhaps KEdit, too? Or how about kfte?) to implement this interface.
> > >=> voila, assuming that we have Torben's kded when this implementation is
> > >done, we would have a globally re-usable editor component! :-)
> > >
> > >And in case of the specific kwrite implementation I'm could think of this:
> > >(assuming that the standard editor interface already exists)
> > >
> > >Split KWrite into four parts (part != OpenPart, just to avoid
> > >confusion :) ) :
> > >1) the KWrite application class (OPApplication)
> > >2) the KWrite mainwindow (OPMainWindow, pretty simple, just have a close
> > >   look at the corba tutorials in kdelibs)
> > >3) the KWrite View (OPView)
> > >4) the KWrite Document (OPDocument)
> > >
> > >Point 3) and 4) would be definitely more work, beside creating the
> > >texteditor interface description.
> > 
> > I guess that KodeKnight already has some IDL representation of editor.
> > IMHO it should be wise to take a look at it and adjust it.
> 
> Yes, it has an editor interface description, but in somehow it is IMHO
> pretty unflexible for a general text editor.
> ...just my opinion. 
> 
> And following Torben's advice to just start writing and IDL and then 

:-)

> discuss it, I had a look in my harddisk chaos to find the texteditor IDL I
> once wrote -> I found it and attached it.

I have some comments:

a) looks nice for a first draft
b) I think TextLine is a good idea, BUTTH: It means that every line is a
   CORBA object. That is expensive since it causes overhead in the 
   POA/BOA.
   I think the more efficent ( but not so nice looking ) approach is to
   move the TextLine functions in the document and add a new parameter
   that tells about the linenumber to use.

Bye
Torben

  > 
> Greetings,
>  Simon
> 

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