Re: [Flamerobin-devel] Main menu - oh no, not again :)

[Michael H. <mic...@el...>]

Milan,

Milan Babuskov wrote:

> We don't want to:
> 
> 1. have menus that change items dynamically when tree is navigated
> since it creates flicker on win2k

let's just say that we don't want to remove and insert menu items at 
runtime very often - changing the caption may work better.

> View, Window and Help menus are clean.

Apart from the fact that we have a disabled Window menu at times, an 
ugly thing.  But more importantly, on Mac OS X there is a standard 
Window menu with commands like Hide and Minimize To Dock, which should 
never be disabled.  I have to try out how FR 0.3.0 works there, 
hopefully this weekend I'll find the time.

> The problem is that you have to have a selected server for "server"
> menu to work, and the selected database for "database" menu to work.

See my previous mail.

> Home
> -Register server
> -[server's items]
> -Quit
> 
> Database
> -[database's items]

That's close to my proposal.

> Database
> -Register server
> -[server's items]
> -[database's items]
> -Quit

That might be good in the future, when Server is no longer necessary, 
but what about users and credentials?

> Still the similar problem. We could solve this by having a dropdown
> list of servers on top of database registration dialog. So, user
> wouldn't have to select a server in the tree.

That is a good idea in general: Make commands in context menus context 
sensitive, but keep such important commands in main menu enabled, and 
let $user select any missing information when necessary.

> It's clear what Properties does for tables, views, etc. For databases
> it could open database registration dialog?

No, I think there are things that should go into a database property 
page: transaction numbers, sweep interval, page size, default charset, 
buffers, ...

> I like to thing in terms: find an object, do something with it.
> Instead of: select an action, and find an object to do it on.
> 
> The first is what context menus offer. The second is usually what 
> regular menus offer.

Here I disagree.  Take any normal application, take Notepad for example. 
  The file menu has commands that are always enabled (New, Open, ...), 
and others that depend on the selected object.  Even better, take any 
MDI application, it's more obvious then that there are several things, 
and only one of them is "selected".  Or take the Edit menu, some 
commands make only sense in the context of selected objects.

> If we build dynamic menus, than that's basically a context menu glued
> to the top of window. There's no gain.

I agree completely.

> Maybe this would be a heresy for Apple, but OTOH maybe they should
> reconsider some things.

I think there is full agreement.  You would find that menus are mostly 
static there, with commands grayed out if not applicable.  It's the best 
thing for users exploring the application, they see what commands are 
there.  Even better, per HIG an application should show hints for 
disabled menu items, so the user has a chance to find out *why* they are 
not available.  It really looks like long research into UI design was 
beneficial :-)

Thanks

-- 
Michael Hieke