Fwd: Re: KDevelop editor interfaces

[Christian Couder]

Hi,

I don't use much IRC so I prefer to give my opinion here.

Cullmann Christoph wrote:
>
> Hi,
> after the little IRC disscusion I want to make my proposal for the hole 
> editor interface stuff:
> 
> 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.

I think the most important interface is between kdevelop and the
doc/view-management-and-editor-stuff.

For example Emacs manage all its views, so if we want a kdevelop
interface with Emacs without rewriting a big part of Emacs, we will need such 
an interface.

Kate also has its own doc-view management, so it could also use this
interface.

In kdevelop 2 we also worked to separate the doc-view management from
the main kdevelop stuff.

So if we decide to work on this interface first on kdevelop 3, there are
3 source code (at least) that could be quite easily used to test this 
interface: kate, the code from kdevelop 2 and the code currently in 
kdevelop 3.

I also agree with the opinion that this interface should be dynamically 
extensible.

Sharing the same kwrite code or not sharing the same kwrite code is not
the biggest problem, because currently the different codes are working
quite well. So it could be done later perhaps with a texteditor
interface or a kwriteeditor interface that would provide only docs and
view, as you say.

> 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.

I agree that it is quite ugly not to have a consistent interface, but
anyway if we want to support the very different editors that the users want, 
we will get something that will not be very consistent. We can't go
against the fact that Emacs and vi and kate will never be consistent.
And we can't go against the fact that user keep asking for Emacs or vi
support in KDevelop.

Instead we can make KDevelop consistent with kate and other kde
consistent editors-and-doc-view-management-stuff like in kdevelop 2 or 
kdevelop 3, so that kdevelop will be consistent by default. And accept
some inconsistencies for the Emacs or vi addict power users.

Bye,
Christian.

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