KDevelop 4.0 UI

[Andreas Pakulat]

On 22.05.09 21:56:22, David Nolden wrote:
> Am Freitag 22 Mai 2009 21:40:14 schrieb Andreas Pakulat:
> > On 22.05.09 21:10:11, David Nolden wrote:
> > > Well actually after digesting this a bit, I think I don't like the
> > > approach of using the tabs to manage areas any more. While it is
> > > intuitive, it clutters the UI up a bit too much, since there is multiple
> > > level of tabs.
> > >
> > > Probably it's better just having some tool buttons that make clear which
> > > area is currently selected.
> >
> > I'll just take this one for my thoughts on this:
> >
> > It tries to cramp too much stuff into too little space. The toolbar area
> > has almost no whitespace, thats really bad usability wise. I also think
> I think that's wrong. Why is it bad for usability if there is no white space? 

Because one needs whitespace to not get the feeling of that thing on the
screen jumping at you with 100 spikes or something like that. _I_ am
used to IDE's and even I feel that the mockup you should completely
overloads the area between titlebar and editor.

> It is good for usability when the important features are discoverable and 
> intuitive.

There's a difference between making a feature accessible and trying to
cramp as much as possible into as little space as possible without any
measuring of what looks good and what doesn't scare people away. There's
a reason Qt creator doesn't put every feature it has into the toolbar.

> I hate wasting space.

Fine, no problem, don't waste it in your configuration of the IDE.
However the default should be something that doesn't scare away new
users and a completely overloaded gui as in the mockup does exactly
that.
 
> > the tabs-in-tabs is bad and in general tabs along the menu or right
> > underneath them looks pretty bad. Also, an area can possibly even change
> > the menu (if it can change the toolbar), so the tabs would need to have
> > everything in them (we could actually do this by having a QGraphicsView
> > with an embedded mainwindow and a tab with multiple such graphicsviews,
> > but I think thats quite a bit overkill).
> I'm still not sure about that. One moment I think the tabs are good, the next 
> not. But they definitely are the most intuitive description of what area 
> switching does, so they should at least be considered.

I find that tabwidget completely ugly and I don't want that in an IDE I
use.
 
> > I don't think we need such a prominent place for switching area's, as
> > thats not something the user should do all the time - except maybe for a
> > Documentation area when we get that). KDevelop should automatically
> > switch the area to the right one, i.e. if an application is started in
> > the debugger switch to Debug Area, if its not debugged anymore switch
> > back to Code area. So yes, some toolbuttons in a toolbar for the last 3
> > used areas should be enough here.
> But it should be clear to the user what's happening.

Sure, I totally agree. But as I said above, the tabwidgets you showed
are the ugliest way of achieving that - IMHO.

> Buttons on the other hand may lead to confusion here, "Where the fuck
> are my documents?"

Well, if we're going to remove editor views when switching between code
and debug, I'm going to fork this project. Thats the most hated feature
in Eclipse I've ever come across. If I want to debug a piece of code, I
naturally _always_ want all files I had open during the coding phase
also in the debugging phase.

> > The toolbar should have standard KDE icon sizes and text underneath
> > them. Forcing it to disobey global KDE settings will get us tons of
> > bugreports that are absolutely correct. Especially new users need the
> > text underneath the icons.
> Not sure about that. I think we should give the user a well usable IDE out-of-
> the-box, and to me that means that it should not waste space.

There's a difference between wasting space and effectively using
white-space. A book is doesn't have text from the top-most left corner
to the bottom-most right corner of a page and there's a reason this
doesn't happen. In the same way there's a bit of whitespace between
lines of text. And similarly we need some whitespace in the GUI of our
application to not make it look cluttered and overwhelm new users with
"things" they don't understand.

> Showing the text on the right side of the icons by default might be an
> option.

As I said, not obeying KDE-wide desktop settings is _not_ an option,
IMHO.

> > I don't think the breadcrumbs view (assuming thats the one we planned to
> > have) should be under the tabs as the breadcrumbs content naturally
> > belongs to the file thats being shown.
> You mean in the toolbar? Not sure about that either.

I'm not actively using the breadcrumbs in eclipse, but the way they show
them at the top of the editing area feels very natural (instead of a
separate toolbar above anything editor-related, also think if someone
puts a toolview between toolbar and editor area).

Andreas

-- 
You will be surprised by a loud noise.