[RFC] KDev4 Ui

Jens Dagerbo jens.dagerbo at swipnet.se
Wed Nov 14 19:38:35 UTC 2007

On Wednesday 14 November 2007 19.40.21 Andreas Pakulat wrote:
> On 14.11.07 19:39:50, Jens Dagerbo wrote:
> > On Wednesday 14 November 2007 18.50.50 Andreas Pakulat wrote:
> > > On 14.11.07 16:00:52, Jens Dagerbo wrote:
> > > > Why isn't the current Document List (or whatever it's called) enough?
> > >
> > > Well, if it automatically re-arranges itself according to my
> > > navigation, it might work well enough. That means when I go from foo to
> > > bar, it should be 1 keyboard-shortcut to go back to bar and the
> > > document list should show that. Same thing for mouse-movement, 1 move +
> > > 1 click at most to go back 1 edit position.
> >
> > I'm not convinced code navigation history (places visited via language
> > support features) and file navigation history (files visited via file
> > switching or opening) mixes well.
> Hmm, do we talk about the same thing?

Probably not. That's how it usually goes.. ;)

> Here's what I'm talking about: 
> a) file-list, a simple listing of files, eventually sorted in the
> least-recently-visited order
> b) edit-history, this includes any positions I have edited (not just
> viewed).
> Afaik thats what we have in KDev3 as well. 

Not quite, KDev3 history adds an entry every time you call 
KDevPartController::editDocument(), so if you use any language bases 
navigation feature to jump between methods in the same file, these movements 
will be recorded and "backable". It also tracks file switching initiated by 
the UI (the tabbar or, in split view, mouse click focus change). It cannot 
track movement brought about by using plain kate features such as jumping 
in-file jumping between bookmarks - the event isn't exposed to us (iirc).

It's easy to remember and recall the point of the _last_ edit, and KDev3 does 
this. But how would you define the point of the second-to-last edit? Where is 
this? Probably not the second-to-last character you typed. Perhaps the last 
edit point that isn't on the same line as the last edit? Very likely you 
would fill the edit history with hundreds of points just writing a single 
function. Perhaps you want to rely on language support to tell you if you are 
in the same function as the last edit and only keep one edit point per 
function or scope? Can you say 'complexity'? :) Or is edit history simply a 
list of _files_ that have been edited? Isn't that almost useless? I don't 
think I would find such a history intuitive or useful.

I'm not aware of any IDE that keeps track of edit history. I'm not even sure 
what such a history would track.

> All I wanted to do is give 
> the latter one a proper UI, because IMHO without UI its not usable - you
> don't see where a "back" or "forward" takes you.

In KDev3 you can press-and-hold the toolbar button to see where you will end 
up, but I never found that too useful myself. You typically "remember" 
where 'back' will take you. Typical use would be something like: you 
click 'QObject' in your code to have a look at qobject.h, once satisfied with 
what you learned you hit 'back' to continue working. That's code navigation 
history. And KDev3 supported this quite nicely. Calling it "not usable" is a 
wild exaggeration.

> I don't necessarily need code-navigation-history, I think plain
> file-history is fine for that. But edit-history would have quite some
> benefits when working on larger files (like the svn plugin class).
> > Eclipse/JDT (dunno about CDT) has both. But it keeps them seperately. You
> > can either chose to go back/forward between code navigation points or use
> > a keyboard shortcut to revisit files in a stack-like fashion (There was a
> > nice patch to KDevelop3 that did this, but, instructively, it was
> > implemented with a parallel history)
> Hmm, seems I haven't dived into Eclipse enough yet. I almost always just
> switch between files there.
Just hit ctrl+back-arrow. Just like any webbrowser. :)

// jens

More information about the KDevelop-devel mailing list