Menu-Structure

[Niko Sams]

On Wed, Feb 17, 2010 at 10:00, Vadym Krevs <vkrevs at serena.com> wrote:
> 2. Why is "Find in files" hidden under Navigation? Every other
> IDE/editor places this menu next to Find/Replace.
I think it is logical. Other editors don't have a Navigation menu.

> 3. The new Editor menu is, well, a waste of screen space for lack of
> better words. You open it, and all you see is 3 other submenus. So you
> have to click on each submenu while trying to locate the one you're
> looking for. The whole point of having a menu is to give users instant
> visual feedback into the list of available operations via a single
> mouse click/keyboard accelerator.
The editor is imho not optimal. But not grouping is also not a good option as
we already have now a lot of main menu entries.
Have you a better idea?

> 4. The primary task of anyone using an IDE is write code in files and
> manage those files. If you spend more time "managing" "projects" or
> "sessions" than working on code in files, then arguably you're using
> the wrong tool, or the tool is making what should be simple
> excessively difficult. That is why placing emphasis on the Sessions or
> Projects menus makes no sense - it is simply not the primary user
> activity in an IDE or an editor.
An important task of an IDE is managing projects and sessions. If you have
no need for this you should probably use for example kate.

> 5. Finally, regarding usability. Believe it or not, some companies
> actually hire dedicated usability experts to design GUIs. The reason
> for this is very simple. Developers, on average, are actually poor
> usability experts, especially in regard to the code they write
> themselves :-)  Some are much smarter then average users, some feel
> emotional attachment to "their" apps, some don't care about users,
> some simply never encounter the issues other users have to deal with
> on a daily basis, and so on  ...  So when someone says he's the
> ultimate usability expert on Kdevelop, it is, well, funny.
no comment on this.

> For example, take Quick Open.  It probably works well for a small
> project like Kdevelop + Kdevplatform when you can remember the name of
> each file/class in the project. Unfortunately, it simply does not
> scale for any non-trivial size project. Have you tried opening a
> 15000-20000 file project in Kdevelop, waiting for the parse to finish,
> then clicking on Quick open and accidentally scrolling the dropdown
> via the scroll bar?
Yes, scrolling is slow. Quickopen is not ment to be used that way.
Does filtering work fast enough with this large project for you?

> Another example, session management - why is a project reparsed from
> scratch when it's added to a session? Why isn't the parse state of the
> project associated and persisted along with the project, so session
> management becomes instantaneous? I read this mailing list, read the
> source, and I know the technical reasons for the current clunky
> behavior, but can you honestly call that "usable"?
I don't think it can be done in another way - the duchain repository simply
can't be stored per project.

> And identifying
> sessions by GUIDs when starting kdevelop from command line is usable?
Just give the sessions a name. We made that naming step optional.

> Finally, why aren't project/session/environment settings storable in a
> file along with the source code so they could be checked into a
> version control system and easily shared amongst many developers?
> Today everything gets dumped into multiple rc files under .kde ...
I think that is a valid point. However getting the user interface right for that
is kind of hard.

Niko