Fwd: Re: KDevelop editor interfaces

[Simon Hausmann]

On Mon, Apr 23, 2001 at 05:42:28PM +0200, Cullmann Christoph wrote:
> Am Montag, 23. April 2001 17:25 schrieben Sie:
> > Am Montag, 23. April 2001 16:59 schrieben Sie:
> > > Am Montag 23 April 2001 16:51 schrieb Ralf Nolden:
> > > > Cullmann Christoph wrote:
> > > > > > Why not :-)
> > > > >
> > > > > Than we should set a date/time for the irc chat. Any proposals ?
> > > > > Perhaps today 21:00 UTC ? or tomorrow ....
> >
> > snip [...]
> 
> >
> > 1. The editor part _ONLY_ provides docs and views (no managment, no
> > windows, no other stuff)
> > 2. The interface supports View/Doc modell, the view and doc are there
> > defined in a abstract way.
> > 3. KDevelop has a generic Doc/view manager for this interfaces to manage
> > them nicely via QExtMDI, QWorkSpace, QSplitter or what you want.
> >
> > If this 3 points are fullfilled, kdevelop would be able to integrate
> > different kinds of editors (like normal text, doc, html ....) into a easy
> > to use and very consistent interface, if the editor part would manage the
> > doc/view stuff each part had an other userinterface, this would just be
> > ugly.
> >
> > (All that is my own opinion, not a official statement of the kate team or
> > so)
> 
> Little example for the persons who think I want to create a big view api :)
> 
> namespace KExtEditor
> {
> 
> class Document;
> 
> class View : public QWidget,
> {
> public:
>   View( Document *doc, QWidget *parent, const char *name = 0 );
>   virtual ~View();
> 
>   virtual Document *document() const;
> };
> 
> class Document : public KParts::ReadWritePart
> {
>   Q_OBJECT
> public:
>   Document( QObject *parent = 0, const char *name = 0 );
>   virtual ~Document();
> 
>   /**
>    * Create a view that will display the document data. You can create as many
>    * views as you like. When the user modifies data in one view then all other
>    * views will be updated as well.
>    */
>   virtual View *createView( QWidget *parent, const char *name = 0 ) = 0;
> 
>   /*
>    * Accessor to the list of views.
>    */
>   virtual QList<View> views() const;
> 
>   [snip .....] what you need else like interface query .....
> 
> protected:
>   QList<View> m_views;
> };
> 
> };
> 
> That would be the API I like (with query interface stuff ... added).
> Doc/View managment is the work of kdevelop's doc/view manager to enable the 
> possibility to use several different editorpart in the same GUI at the same 
> time. (to write docu while coding ....)
 
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? :)


But maybe I'm missing something. I bet Bernd knows more about whether this is
feasible or not (due to his kwrite integration in gideon) .

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«