KDevelop editor interfaces - ups

[Richard Dale]

On Fri, 27 Apr 2001, Matthias Hoelzer-Kluepfel wrote:
> Am Freitag 27 April 2001 10:49 schrieb Richard Dale:
> 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.
Even if we were to stick with just Kate, it would make sense to implement a
better interface as you say. 

One example problem is to identify the current selection (not the
same as the contents of the selection clipboard) - ie it is the item (eg text,
or a filename, or file contents) that is currently selected on the widget that
has user focus. 

It would be nice to be able to write a menu option to obtain that current
selection and replace it with something else. So you could add a 'pipe...' menu
option, which would allow you to select some text, bring up the pipe dialog and
type in a shell expression. Select a four column table, and type a command like
awk '{ print $3 }', then you run the pipe it would select the third column of a
table, and replace the selected text with that.

> 
> 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 :)
I have grown up on non-modal editors (certainly since MacWrite, when I first
owned a Mac in 1984), and I don't think you get attached to those, in the
same way as you get attached to diffiicult to learn highly modal editors like
emacs. 

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

> > 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. 
Does the integration have to be 'in process' - is it possible to get KDevelop
to message nedit via DCOP? It could be told to open/close files, highlight a
range of text lines etc. That is how NeXT integrated the Edit app with the
ProjectBuilder IDE, and the gdb front end was also another process.

> 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? 
I think I agree with all that - this is a healthy design review - I see no
conflict! I'm only slightly wary of over-ambitious goals after the demise of
KDevelop 3.0 mark 1. That wanted to start off doing everything for everyone,
and it all got too difficult to get the framework off the ground. As long as we
always have a working/or nearly working IDE, people will contribute, and it can
grow incrementally.

-- Richard


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