On 04/09/13 07:08, Roman Kantor wrote:
> 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
Right.
> 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)
Yes, I could see where that would be a PITA, and have noticed it myself
in my own apps that use a list of checkboxes in a "preferences" submenu.
Arguably one should create a dialog for such things as preference
panels,
as menus tend not to be a good interface for such things. I use them
myself,
and realize as my app has matured, I should really make a preferences
dialog.
Still, I'd agree changing radio boxes/check boxes in menus probably
shouldn't
close the menu, and perhaps should be 'new' default behavior, with the
old
behavior selectable with a flag.
I don't know much about FLTK's menu internals, but perusing Fl_Menu.cxx,
it seems that while one is navigating the menus, the variable pp.state
maintains the current state of navigation while a menu is open, and
it's only
when that variable is set to "DONE_STATE" that the menus close.
Also: while sniffing around in Fl_Menu.cxx where I thought this change
should be made (around FL_RELEASE), I noticed this commented out section
(with #if 0) that might actually do what you want (see ***):
case FL_RELEASE:
// Mouse must either be held down/dragged some, or this must be
// the second click (not the one that popped up the menu):
if ( !Fl::event_is_click()
|| pp.state == PUSH_STATE
|| (pp.menubar && pp.current_item && !pp.current_item->submenu()) //
button
) {
#if 0 // makes the check/radio items leave the menu up ***
const Fl_Menu_Item* m = pp.current_item;
if (m && button && (m->flags & (FL_MENU_TOGGLE|FL_MENU_RADIO))) {
((Fl_Menu_*)button)->picked(m);
pp.p[pp.menu_number]->redraw();
} else
#endif
So it looks like someone's already been here with that in mind.
If uncommenting that works for you, I guess we should add a flag,
as you say, that lets the app control this. Otherwise, we're open
to patches..
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
