KDE/kdevplatform/shell

Alexander Dymo dymo at ukrpost.ua
Sat Nov 8 21:59:07 UTC 2008


On Saturday 08 November 2008 17:41:17 Niko Sams wrote:
> What about dropping this "open files" idea completely? We have quickopen,
> we have a Context-Browser "back" action and we could probably have a
> recently opened
> files list. There could also be favorite files list - so you can mark
> the files your are working on.
>
> Internally the latest files can still left open (faster).
> Files with unsaved changes also must stay opened.

I also support this idea and here's why:

In KDevelop we support several usecases for "opened" files which we can 
continue to support without a concept of "opened" file.

1) files from project which you work on
 -> present solution: "quick open opened files" (+tabs)
 -> possible solution: just regular "quick open file"
 -> rationale: when you have more than 10 opened files "quick open file" 
dialog is not really different from "quick open opened file" - the list is 
long enough and you simply have to type. I myself never use the "quick open 
opened file" exactly for this reason.

2) files from other directories on disk / network files which you work on
 -> present solution: "quick open opened files" (+tabs)
 -> possible solution: "quick open recent file" + usual recent file history 
implemented in "documents" toolview
 -> comments: this is quite important problem, we don't really have a good way 
to work with files from outside the project. Can't say anything here without 
trying.


==================

On tabs:
Let's stop thinking about tabs and its problems for now, but think instead 
about usecases.

My usecase for tabs is following:
- I usually have 3-6 opened files which I work on simultaneously. It is really 
convenient to switch between them with alt-left and alt-right. 
- When I open files which I don't intend to edit, I have to close them after 
viewing to keep my list of opened files short
- "Close all others" is the function I use constantly to keep the list of 
opened files (and tabs) short

In short, tabs for me ARE:
- the way to switch between a specific SET of files I work with

For me tabs are NOT:
- the way to have overview on project (they don't fit on my screen)
- the way to switch between opened files (again, they don't fit on my screen)


Following features can cover my usecase with tabs and let me not use tabs:
1) Explicit "editing session" with a list of files - I would have to use some 
shortcut to add file to the session and some shortcut to remove file from the 
session. 
Extra mental work to manage this "editing session" doesn't bother me because I 
already do that.
Alt-left and alt-right shortcuts should switch between files in this "editing 
session".
The file selector (or documents list) could show this editing session in a 
split view or it might be a separate toolview (we surely need to be able to 
show two toolviews at the same time).

2) The list of "recently edited" files ordered by last edit time or, 
optionally, by editing frequency.
Alt-left and alt-right shortcuts should switch between files in this "recently 
edited" list. 
Again, this list might be a part of existing toolview or a toolview on its 
own.

Personally, I'd rather like to try the 2nd idea and see if it works for me.


==================
Please share your usecase for tabs and let's think if we can cover all of 
these without tabbed interface.





More information about the KDevelop-devel mailing list