On 09/04/2013 15:40, MacArthur, Ian (Selex ES, UK) wrote: >> >> 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.
There could be some reasons (maybe there is assigned callback to it too or ... whatever), that's why my proposition is not to change default behaviour but to have this purely optional flag FL_MENU_NOCLOSE > > >> 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. You are right, probably all (most) toolkits behave like fltk in point (2) but it would be nice to have also different option. For instance I have a "status bar" which can show several values, and right click pops-up a menu with checkboxes to allow user to select only values he wants to display. In such cases it would be nice to have different behaviour (I know I can always write a popup window, but right-click popup menus are simple and very common too...). > > 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... You would need to write new pop-up function (the menu pop-up calling code is relatively messy) and then derive all the widgets (menu-bar, menu-button, choice, ...) with handle() overridden to call this new menu pop-up. So I thought that if it would be of interest of other fltkheads, this could be addition to the library. > Anyway; just tell your users to be glad you are not trying to foist some > "ribbon" interface on them! Yeah, those ribbons take half of the screen space and dance around like on ecstasy so you never know where to find the animal you want. R. _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
