Fwd: Re: KDevelop editor interfaces

[Cullmann Christoph]

Am Montag, 23. April 2001 18:26 schrieben Sie:
> 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?

First, the importants thing is to have a view class itself, even if it is 
only a Qwidget without any more specific api. Than a document() is just just 
nice, for example if you click on a mdichild (a view of a doc) and hit the 
close button in the filemenu/toolbar, that the generic kdevevelop 
doc/viewmanager needs to know which document he must kill after the view is 
deleted.

cu
Christoph

>
> (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«

-- 

| |   / /               - get an edge in editing -
| | / /                      »»»» GET KATE ««««
| |/ /      a fast and capable multiple document,
|     \     multiple view text editor for KDE
| |\  \     cullmann at kde.org
| |  \  \   http://devel-home.kde.org/~kate

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