KDevelop editor interfaces - ups

Richard Dale Richard_Dale at tipitina.demon.co.uk
Thu Apr 26 16:52:20 UTC 2001


I agree with Bernd that a special doc/view manager sandbox would be a good
idea. In my opinion adding multiple editor support, ie non-modal Kate/KWrite,
emacs, vi + assorted other optional editors is a low priority in improving the
usability of KDevelop 3.0. They are more important issues if you are developing
a reusable editor part like Kate - and there is nothing wrong with Kate/KWrite
developers being interested in generic editor component interfaces.

But I don't think KDevelop HEAD should be turned into a test bed for getting
various unusual window management UI's/editors working. Why do editors need to
manage windows? I don't know, the discussion is all beyond me :-)...

The current framework is already proving its worth. For instance, I tried the
code reformat option last night - it works great on java, and just adds a
single menu item to do something useful. And you can set up the plugins you
want enabled quite easily with Mathias's option setting plugin. The java
jdb debugger will fit in quite nicely when it's done, and be able to run
concurrently with the gdb frontend. Both debuggers are optional and just add
the menu items they need, and so on...

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.

-- Richard


On Tue, 24 Apr 2001, you wrote:
> On Tue, 24 Apr 2001, Cullmann Christoph wrote:
> > P.S.
> > only a test, will be removed from cvs after making a real docviewmanager.
> 
> Ehem, instead of distributing several different attempts all over
> kdevelop's directory hierarchy, what about moving this to kdenonbeta? 
> There we can do anything without having to care about breaking 
> unrelated code ;-)

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



More information about the KDevelop-devel mailing list