[RFC] KDev4 Ui

[Adam Treat]

On Wednesday 14 November 2007, Jens Dagerbo wrote:
> 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

FWIW, I agree with everything Jens said here.

Adam