KDevelop editor interfaces - ups

[Cullmann Christoph]

Am Freitag, 27. April 2001 13:09 schrieben Sie:
> 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?
;-)
Build a nice doc/view editor interfaces -> I will implement a part if you 
stuff is interface stable ;)

cu
Christoph

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

-- 

| |   / /               - get an edge in editing -
| | / /                      »»»» GET KATE ««««
| |/ /      a fast and capable multiple document,
|     \     multiple view text editor for KDE
| |\  \     cullmann at kde.org
| |  \  \   http://devel-home.kde.org/~kate

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