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

> 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 
        as menus tend not to be a good interface for such things. I use them 
        and realize as my app has matured, I should really make a preferences 

        Still, I'd agree changing radio boxes/check boxes in menus probably 
        close the menu, and perhaps should be 'new' default behavior, with the 
        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()) // 
        ) {
#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))) {
      } else

        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

Reply via email to