[Fwd: A new IDE for a new milleneum :-)]

[Christian Couder]

On Sun, Apr 01, 2001 at 11:17:45PM +0200, Bernd Gehrmann wrote:
> On Sun, 1 Apr 2001, Christian Couder wrote:
> > If your IDE makes it harder to come to this goal, why would I support it
> > ?
> 
> Harder than what?

Harder than using KDevelop 2 or the current KDevelop 3 to reach this
goal.

> > > Ief you give me an embedabble emacs component with an
> > > interface that has everything kwrite has, I'll
> > > give you an emacs-enabled kdevelop in 10 minutes.
> > 
> > You know it doesn't exists so you take no risk by saying this...
> > 
> > Now could you integrate Kant/Kate in ten minutes ? 
> 
> It is already integrated, just with a different name :-) 

It's not really true because it is not integrated as a "component".
It is integrated as source code only.

> If you find it more aesthetical, you can of course add a
> factory class to lib/kwrite/texteditor.cpp, and declare
> all virtual methods in a separate interface and add a .desktop
> file. But it is certainly more logical to fix the kant/kate/
> whatever name is fashionable today's part instead and use it 
> when it is finished. 

I think it is nearly finished and we could already start integrating it.

And you know that we will have to finish KDevelop 2 anyway so we will 
also have an editor and view management that works in it.

So if we can make your app use an editor and view management component,
there will perhaps be three components to use: the kwrite/kant/kate 
component, a component made from the docview manager in KDevelop 2, and
another component made from you own editor and view management.

Also in this case at least we wont drop Falk's code, and we will make it
possible to integrate other editors latter.
 
> > And even if you could, then why did you say in a previous mail that "the
> > buffer/view semantics are very much integrated in the Core class" ?
> 
> Because they are. The buffer/view stuff basically needs the constructors
> for TextEditorView and TextEditorDocument and the method to load a file.
> It is fundamentally based on the concept that you have a document class
> which corresponds to a file, and can create view instances for a given
> document which are for their whole lifetime attached to the same document.
> Not every editor does it like this. For example, in emacs, any lisp
> expression can potentially change the buffer that belongs a given window.
> Other editors may not support multiple views per document at all, or not
> support 'pure' documents without any view. Qt is even more different:
> Without hacking the QText sources, the api is such that with every
> QTextEdit you instantiate, you also create a document. After the creation,
> you can set the view to a different document.

So perhaps I misunderstood you because I thought that it meaned that it
would be difficult to make your app use a component for the editor and
view management. But I think you should state it clearly (or you should have 
stated more clearly) that you find no objection to make your app use a
component for the editor and view management.

Bye,
Christian.

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

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