KDevelop4 features (Was: change of maintainership in KDevelop)

Vladimir Prus ghost at cs.msu.su
Wed Apr 5 11:48:04 UTC 2006

On Wednesday 05 April 2006 13:28, Hamish Rodda wrote:

> > Personally, I think that KDevelop is pretty bad when it comes to
> > real-world use-cases. For example, I'm just now looking at Eclipse's code
> > in Eclipse, and going to class declaration with one click, and going to
> > list of all uses of a method in one click are both extremely handy, and
> > missing in KDevelop.
> Whenever you want to switch your debugger work to kdevelop4, I'm ready to
> help you get some stunning results for the debugger <-> editor integration
> :)  

I'm not yet sure when I can switch fully, but maybe we can discuss/plan right 
now? I already have several specific ideas what can be improved on Kate part.

> I did have a debugger port (only took about an hour) but it was going 
> to suffer bitrot so we removed it for now.  Perhaps when MI is stable?

Guess I'd need a couple of weeks to finish MI porting, and then unspecified 
time will be spend on fixing bugs in the resulting thing.

> > For another example, consider the use-case of applying a patch. Ideally,
> > KDevelop should be able to guide a developer from receiving of email, to
> > applying, resolving conflicts, building, testing, and comitting
> > (including auto-composing the list of changed functions for commit log).
> I want to provide external tool inlining which should help kate be
> integratable into kdiff and friends, and then hopefully this will be
> better.

That would be cool. But what specifically do you mean about external tool 
inlining. One approach on KDevelop side would be to just embed KPart and show 
it inside the tab widget used to select files. No support from Kate is 
necessary. Or it might be possible to use some plugin interface for Kate, 
that will make, for example, chunks of a diff file appliable with a click, or 
something like that.

> > Or consider SVN integration. Ideally, I want to select "Annotate" command
> > somewhere and see revision numbers on the left of the edited text, with
> > all revision numbers clickable and leading to log message for that
> > revision and full diff for that revision.
> Ditto.  I also think we need to use libsvncpp if it's mature, to get the
> benefits of being able to use the local .svn directory.

On Kate side, we'd need:

  - Ability to add custom area on the left of the text with content rendered
    by KDevelop
  - Ability to make some word clickable.

And while we're at it, another Kate idea I have is this. Now, if compile ends 
with an error in KDevelop, we don't seem to jump to the first error at all.
I think it would be nice if we:

  - Jump to the first error
  - Right inside document, show the error message in a box

This way, the error message is close the the location, and the message window 
on the button can be just hidden.

Yet another editor-related wish is this. Say you open a file that's in 
"conflicted" state. It would be nice if, above the document itself, but in 
the same window, you'll see box saying:

  "File has conflicts. Showing first one, press F3 for the next"

Some kind of context help right inside document window.

What would you say?

> > And so on. It would be good if we collect all such ideas and put it to
> > Wiki.
> >
> > Maybe of ideas can be implemented right away, with Qt4, or maybe with
> > reliance just on Kate. That's probably be a good way to attract new
> > developers.
> We really need a kick-ass c++ support part to do all this, 

Not all depends on c++ support, though.

- Volodya

More information about the KDevelop-devel mailing list