> I have got a number of complains from end users how the menu items
> behave - probably different than they are used to or how other toolkits
> behave.
> The complain is that clicking on ANY item causes the whole menu to
> close, even if it is:
> 
> 1) A submenu. Usually submenu is just an entry point and "mouse
> hovering" opens the submenu automatically, an accidental clicking on
> this entry point should not
> close the whole menu. "Not closing" the menu would also indicate that
> no action was performed and choosing particular submenu-item is
> required to invoke an action

Yes, this has come up before - I remember it being discussed, have no 
recollection whatsoever what the outcome was... Though it does not appear we 
changed anything... 
Presumably there was a reason for the current state.

ISTR someone (maybe Greg?) posted a table showing how the "native" apps on the 
host OS usually behaved, for comparison with the fltk behaviour.

Or I might be making that up...



> 2) If menu item group is set of check-boxes (I have some application-
> settings options as menu checkboxes) and user wants to change a few
> settings at the same
> time, he/she needs to reopen the menu for each single item change.
> Sometimes user re-opens the menu even for single change just to
> visually confirm that the
> state was changed. In such a case they expect that menu closes only if
> you either hit "Esc" or click menu-opening widget (menu-bar or menu-
> button)

Is there any toolkit that does that? I don't recall seeing that behaviour - 
though it sounds useful. 
Certainly, the "native" Windows apps I've been using recently, with check-box 
like menu entries, do not seem to show the desired behaviour; they seem to 
behave pretty much as fltk does.


> My proposition would be to to have additional flag which could be OR-ed
> to other menu-item flags (like FL_MENU_NOCLOSE or so) so the behaviour
> is
> backward-compatible but the developer has better control how the menu
> behaves.

It might even be possible to make that behaviour be deriving a "better" menu 
class?
Not sure.
Oh, that's odd; having typed that, I have a vague déjà vu of having tried to do 
that in the past, then giving up...


Anyway; just tell your users to be glad you are not trying to foist some 
"ribbon" interface on them!

Cheers,
-- 
Ian
(Who recently was "upgraded" to Office 2010 by an apparently ungrateful 
employer...)




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 
3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to