KDevelop4 UI

David Nolden zwabel at googlemail.com
Mon Dec 21 17:08:48 UTC 2009

Am Montag 21 Dezember 2009 17:52:29 schrieb Alexander Dymo:
> понеділок, 21-гру-2009 15:47:30 Andreas Pakulat ви написали:
> > On 21.12.09 13:45:36, David Nolden wrote:
> > > Btw. if we should try this out and see that:
> > >
> > > Sessions  Project  Navigation  |  File  Editor  Code  | Window 
> > > Settings Help
> >
> > I think I actually do agree (after a longer walk outside and some time to
> > getting used to it) on the "more sense" part for your fully re-ordered
> > version. Maybe we should just try it out sometime soon (i.e. do the fully
> > re-ordered version) and then see what feedback we get.
> Guys, please don't forget that it's more important to provide _familiar_
> environment for the user, rather than logical.
> Every other application out there has "File | Edit |...". All other IDE's
>  do that too - Eclipse, Netbeans, Idea, MSVC just to name a few :)
Actually I think that this is one of the reasons why "Menus" are considered to 
be annoying and unusable, because in nearly all applications they don't have a 
logical structure. Even KMail has a "File" menu entry, how broken is that? I 
never know where to search for a specific function.

Also, I heard/read many complaints that our menu sucks, while I have read 
mostly positive comments about most of our "New" stuff, so "New" stuff seems 
to be less of a problem for our target audience. Also, at our current main 
competitor Qt-Creator nearly _everything_ is "New" except the menu, and all I 
hear is how logical their UI is, so the logical part does seem to play a role.

Apart from that, if we leave the "Edit" menu out of the "Editor" submenu, we 
will still have the common "File | Edit" pattern, it will just be a little to 
the right, but people may recognize it. Also with this structure, they may 
intuitively understand what a "Session" does, which is quite important, as we 
a) don't have a manual, and b) if we had one, users wouldn't read it anyway. 

> We already have enough "differences" in the UI - area tabs, workingset
> buttons. And I recall somebody already complained about that (in kdevelop
>  ml?) Please let's not introduce another one.
> PS: I definitely agree on a other structure David proposed.

We can try out the effect of the re-ordering and see how it works. After all 
the re-ordering itself is implementation-wise just a minor detail. The 
restructuring of the menu will be more complicated.

Greetings, David

More information about the KDevelop-devel mailing list