Breadcrumbs implementation - patch

David Nolden zwabel at googlemail.com
Sat Dec 20 19:55:45 UTC 2008


Am Donnerstag, 18. Dezember 2008 19:52:57 schrieb Andreas Pakulat:
> > I am thinking of modifying the tab-widget so it supports grouping and
> > maybe even a very simple "tree" like management, this could also be the
> > interface for the planned working-sets. For now, the tabs only work
> > properly for up to 5 files, but that's still better than nothing.
>
> Do you need this information available all the time? Or could it work
> similar to the uses-widget, i.e. its easily triggered by a keystroke. So
> say you hold down Ctrl then a 90% opaque list of open files, sorted in the
> least-recently-used order comes up, you can navigate the list and jump to
> an entry. This would scale a lot better than tabs and we could provide
> other orders than least-recently-used...
I think it would be useful, although probably not mandatory. I might get used 
to not seeing them all the time, but it's especially useful when in 
mouse-mode, so you can get to any open file with a single click.
> IMHO working-sets is a bit different beast, because you usually set one up
> and then switch between them, closing/opening files as needed. Tabs are a
> way to easily see what you've got open right now and also to navigate among
> these files with the mouse. But for mouse navigation a bread-crumb is
> almost as good as tabs, it requires 1 click more in "worst case", but in
> best case it requires a lot less clicks than tabs with their navigation
> arrows.
My idea is that this would be the same thing. If you don't create working-sets 
explicitly, they would define themselves. For example, if you have really 
many files open, then your working-set would only be the files in exactly the 
same directory. If you have less files open but multiple projects, your 
working-set would be all files from the current project. You could always get 
to the other working-sets in a tab-like manner.

So in "implicit" mode this would just hide away the "less" related files, 
which is better than seeing a totally random choice of 5 files in a 30 files 
long tab-widget.

> However I actually don't care anymore too much about this for me
> personally. With kdev4 I have 1 shortcut to jump to any file, wether its
> open or not, because opened files are grouped at the top of quick-open. All
> I'd like to have is a proper navigation history (not sure we have that yet,
> if we do I just need to learn to use it).
Navigation-history exists and works, use the previous-context and next-context 
shortcuts of the context-browser. It just has one little bug that it 
sometimes messes up the order a little bit so you have to jump back+forward 
to get back.

Greetings, David




More information about the KDevelop-devel mailing list