[Kde-accessibility] do we need menubar in kmag?

[Bill Haneman]

On Wed, 2003-01-29 at 12:43, Gunnar Schmi Dt wrote:
> Hello,
> 
> > This topic was raised recently on the list and I wanted your opinion.
> > Earlier versions of kmag had a menubar, but then I decided to get rid of it
> > since it was not serving any purpose. kmag is not a file driven
> > appication.. there are no files to open or close, so I decided to just have
> > a toolbar.
> >
> I think that a menu bar is not only needed for file driven applications. In my 
> opinion an application should have a menu bar if it has a tool bar. Off 
> course you could add options to hide both the menu bar and the tool bar 
> (independently from each other).

This can be important from an accessibility perspective; most toolkits
support full keynavigation of menus but only partial keyboard navigation
of toolbars.

Thus it's essential that every toolbar operation/feature be available
via menus, in order to ensure that all features are available to
non-mouse-users.

Even for toolkits that support keyboard navigation of toolbars, the menu
conventions have come to be expected, and every application that offers
menu-or-toolbar-style user interfaces is expected to have menus
available via a common menu-posting keybinding (for instance F10).

regards,

Bill


> 
> > Here is what I plan for the future:
> >
> > 1. As Iain Murray suggested, kmag will have a separate window with all the
> > options since it will be easy for those with vision problems to locate the
> > options all in one place. To open the option window, I will add a button to
> > the right of "selection window" (bottom).
> >
> If you want a configuration dialog, I would put the button for opening it into 
> the menu bar and into the tool bar. The bar with the buttons has already a 
> large minimum width. (I usually want to use the full height of the screen for 
> editor windows or browser windows, so that such windows as KMag get placed on 
> the side of the screen. There they must not have a too large width).
> 
> > 2. I will add two profiles to kmag. One for visibility impaired people and
> > the other for graphics designers/image processing researchers who just need
> > it for zooming a part of the screen. We can also have two desktop files
> > which go in different places in the menu.
> >
> I do not think that two profiles are necessary if KMag has enough options to 
> customize the user interface (hide the menu bar/tool bar, configure the icons 
> in the tool bar/the short cuts etc.)
> 
> > So the bottomline is that I do not think the menubar is necessary. It
> > simply wastes screen space.
> >
> In my opinion KMag needs a menu bar. But it might not need the bar with the 
> buttons if you put them into the menu bar. For the case that both the menu 
> bar and the tool bar are hidden, you could place the most important functions 
> into a pop up menu.
> 
> Gunnar Schmi Dt
> 
> P.S.:
> As the deadline for i18n-string changes is already this friday, I sugest that 
> you do the changes to the user interface after the release of 
> kdeaccessibility (i.e., for KDE 3.2). For the release it would be nice if you 
> could have a look into the version number of the application (It does not yet 
> have the version 3.2, has it?)
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility
-- 
Bill Haneman <bill.haneman@sun.com>