[RFC] KDev4 Ui

[Jens Dagerbo]

On 11/14/07, Kris Wong <wongk at seapine.com> wrote:
> > Thats similar to what eclipse has, but it doesn't scale
> > either, think of
> > those "insane" Jens Dagerbos out there that have 40 files
> > open at the same
> > time.
>
> I would say, for those users, we are trying to solve the wrong problem.  Nobody is going to be actively editing 40 files at once.  This were David's idea of working file sets would be uber handy.  This would allow the user to easily switch between different sets of files that are open for edit, and could significantly cut down on the number of files that have "represntation" in the tab widget at any one time.  IMO, this seems like the problem should be trying to solve.
>
Since I even seem to represent this problem, I guess I should weigh in.. ;)

It's NOT about the number of files being actively edited.

I doubt you at any given point "actively" edit more than 3-4 files.
For this case, just about any widget scales. But and IDE isn't just an
editor, and what I at least want from an IDE is _navigation_ support.

Common scenario when I was working on KDev3: Half a dozen files open
that I was semi-actively editing. Some conversation in #kdevelop or a
new bug report prompts me to look at a number of files in for exampel
the UI and debugger code, trying to understand a focus bug. Rinse,
repeat. It doesn't take long for the number of open files to reach 20,
and this is already past pretty much any widget's scalability except a
listview. Sure, I could go closing the 8th file every time I wanted to
look in a different file to make sure the tabwidget didn't grow too
fat, but I doubt any of us would like to see KDevelop require this to
stay usable.

"File sets" doesn't solve this. They are just the
remember-to-close-before-you-open idea on crutches. At least for this
problem. File sets could perhaps be nice for other use cases. I can't
quite see them.

Tabwiget+dropdown is, as Andreas pointed out, still not scaleable.
It's marginally better than horizontal scrollbars on the tabwidget,
but they don't offer a uniform overview and they have an upper limit
where they go really uncomfortable.

Why isn't the current Document List (or whatever it's called) enough?
It actually scales and can additionally house many more actions than a
dropdown list. (VCS actions, file actions, etc)


About the UI - don't make the same mistake as KDev3 - pick one UI mode
and stick with it! Attempting to develop/test/debug UI-features for
the multitude of UIs KDev3 had was horrible. It pretty much guaranteed
that whatever problem you tried to solve, you were stuck with the
lowest common denominator (which still didnt't work). Actually
committing to one UI mode would make it much easier to develop a
sensible and predictable user interface.

// jens