KDevelop editor interfaces - ups

[Matthias Hoelzer-Kluepfel]

Am Freitag 27 April 2001 10:49 schrieb Richard Dale:

> I think you have two goals here; one to add better interfaces to the
> existing single editor implementation to get 'the currently selected text',
> 'the current file', 'all project header files' etc for scripting. But there
> is a second goal, which is to make these interfaces so complete, that you
> can just slot in another editor part with a different UI paradigm, and it
> will all 'just work'. I agree with the first goal, but I'm not sure that
> the second one is achievable (I have no problem with being proved wrong on
> that).

Richard,

this is a very concise description of the problem. Perhaps I have not made 
that point clear enough. Here are my thoughts:

a) we need a clean interface to the editor implementation

This can be, of course, as easy as saying: "The editor is Kate, so we use 
whatever Kate uses as interface". This is more or less easy to do. But it 
also has drawbacks, for example exposing unnecessary kate details to the 
parts. The problem with that is, once parts are using that details, you have 
to provide them for all times, or the parts will break. And this sounds like 
a bad design to me, even if I know that it is doable.

b) the interface should be generic, abstract, just to make parts easier to 
   develop

This is the main point. I started with this thinking when I saw the the 
astyle plugins has no clean interface, and is somewhat hackish for that 
reason.

c) My guess (or my hope) is, that if we get that interface right, we can
   plug in another editor

This is in fact the third priority. But don't underestimate the appeal of 
that possibility to developers that didn't grow up with KDE, like we did :)


> If 'adding extra editor support' means just adding the keybindings from the
> original editor, to a single standard part (Kate/Kwrite), then that is
> straightforward and achievable. I think I get suspicious when I read ideas
> about the editor part doing its own window management - KDevelop should be
> doing that, it is the application in charge. Are we writing an editor which
> happens to be an IDE, or and IDE which is trying to be an editor.

Two responses:

a) The editor should not do the window management. This is why we need a 
clean interface to KDevelops window management.

b) I think we should write an IDE. An IDE that makes use of an editor where 
an editor is needed.


> So what does the guy love about nedit? Is it the keybindings, window
> management, or some lisp scripting environment or whatever? What would be
> the minimum to make him happy - would adding nedit keybindings to Kate be
> sufficient?

No, he wants to use nedit. He likes the KDevelop class browser, but he just 
prefers nedit to the built-in editor. 


One thing: I don't see why this is dramatised to a big conflict. The 
different goals are not contrasting. I like that you add Java support. I am 
interested in adding a nicer part-interface, and some more flexibility on the 
editor side. Christoph wants to have the best editor implementation 
available, so that people no longer _want_ to use emacs or nedit. Where is 
the problem with doing all that, so that KDevelop will be as good as 
possible? 



Bye,
Matthias.

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