Fwd: Re: KDevelop editor interfaces

Simon Hausmann sh at caldera.de
Mon Apr 23 16:26:21 UTC 2001


On Mon, Apr 23, 2001 at 06:20:24PM +0200, Cullmann Christoph wrote:
> Am Montag, 23. April 2001 18:13 schrieben Sie:
> > On Mon, Apr 23, 2001 at 06:09:58PM +0200, Cullmann Christoph wrote:
> > > Am Montag, 23. April 2001 18:03 schrieben Sie:
> > > > Am Montag 23 April 2001 17:55 schrieben Sie:
> > > > > A comment about the views:
> > > > >
> > > > > I would not expose the views through the public interfaces. I believe
> > > > > views should be an implementation detail of the editor. Imagine a
> > > > > editor which does not support multiple views at all, or a editor
> > > > > which implements views as children of an internal tab widget. (or a
> > > > > emacs gnuclient frontend, with no views at all) . The only thing I
> > > > > would put into the public interfaces is some way to pass a parent
> > > > > widget through. But for the rest I would keep views away from the
> > > > > interface. (what do you need them for, anyway? :)
> > > >
> > > > That is exactly the point. The interface should start with the smallest
> > > > common denominator, and aggregate more complex interfaces. Why should
> > > > kdevelop care about the views? There is no sense in separating the
> > > > views from the document, and then exposing the views. KDevelop needs
> > > > access to the document, and the view management should be the concern
> > > > of the editor part.
> > > >
> > > > I also think that if there is a interface that can only be implemented
> > > > by kate (and perhaps another new kxyz editor), then it is not worth to
> > > > create such an interface at all. Then we could just link against kate
> > > > directly. But I think we would loose a lot of potential in that case.
> > >
> > > With your interface kdevelop will loose its nice gui which is usable.
> > > There will be no nice way to use 2 editor parts at once, like text, html
> > > + a docu editor within a nice GUI because not all these parts are managed
> > > by one doc/viewmanager, you will end up with 10000 windows with different
> > > gui, shortcuts ..........) Than each dev can use emacs + kdbg + gcc +
> > > konsole, that will be more easy to use.
> >
> > I'm not sure I understand this...
> >
> > Why do you need a special doc/view manager just to arrange a few widgets?
> >
> > Why no let the editor implementations create their views as children of a
> > QWorkspace or one of Falk's MDI widgets?
> That is a doc/viewmanager ! But therefor you need a view class (k, am minimun 
> one with one funtion document() and you got it, thats all I want), but I dont 
> want a editor which starts as a external app and don'T fit into the GUI, 
> thats no integration.

But why do you need a view class which provides a reference to the document if
all you want is to create a widget as child of a MDIWhateverFrame?

(sorry if I'm missing the point :-}

Bye,
 Simon

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop-devel mailing list