KDevelop editor interfaces - ups

[Cornelius Schumacher]

On Friday 27 April 2001 10:49, Richard Dale wrote:
>
> 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).

I think the second goal is not to make the editor interface complete but to 
provide an extensible interface, which makes it easy to use different editor 
parts, which in most cases will only support a subset of all the 
functionality theoretically available through an editor. This is important 
because it makes integration of other editors with kdevelop easy.

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

The goal of kdevelop should be to write an IDE, not an editor. There are 
plenty of really great editors out there. What an IDE should provide is 
integration between components. I don't mean the visual integration by 
putting them together in one window. That might be a nice side effect but 
what is much more important is that the components interoperate well in terms 
of exchange of data and control. The great thing about the HEAD kdevelop 
framework is that it makes it very easy to put together specialized 
components in a common framework.

> > > The number of people who would move to KDevelop 3.0 because of emacs or
> > > vi support is much smaller, compared with the numbers you can get by
> > > doing, say, customised java or python programming environments. I would
> > > like the idea to be to try and make KDE programming easier for the
> > > average programmer, so we pull more programmers away from lesser apis
> > > :-). But too much emphasis on bells and whistles for the real
> > > programming wizards (ie emacs users) won't do that.
> >
> > Again, you are correct, but getting an interface right does
> > not mean that it will be any harder to use for an average
> > user.  Most of the time, it will get easier.
> >
> > And about editor fans: I happen to know one experienced
> > KDE developer who started to use KDevelop 3.0 after just
> > _showing_ him how he could integrate his loved nedit into the
> > framework. (I won't talk any more about that. He is following
> > this list closely ;)
>
> 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?

I'm the guy using nedit and I can say that it certainly isn't because of the 
key bindings. I switched to nedit a couple of years ago because I liked the 
nice rectangular selection mechanism, the clean and efficient user interface 
and the syntax highlighting for Verilog. But it is more than individual 
features, why I like nedit, it's also because I'm used to it and it is hard 
to break old habits :-).

By adding a nedit part to the editor framework of Matthias I suddenly was 
able to use the kdevelop class browser with my favourite editor. I didn't 
have to change any of my personal preferences, just got an additional 
benefit. That's the great thing about a powerful component technology.

Cornelius

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