Menu behaviour...

[Roman Kantor]

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)


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.


Roman

[MacArthur, Ian (Selex ES, UK)]

Post by Roman Kantor
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.
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...

Post by Roman Kantor
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.

Post by Roman Kantor
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.
********************************************************************

[Greg Ercolano]

Post by Roman Kantor
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.
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.

Post by Roman Kantor
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..

[Roman Kantor]

Thanks,

I have implemented functions to control the menu behaviour, patch submitted as feature-request STR #2950.

The implementation is very conservative (does not change current behaviour) not to break current applications but adds the programmer various possibilities how
to control when the items should close the menus.

The API consists of two additional functions, they are implemented as "static" of Fl_Menu_Item namespace:

class Fl_Menu_Item {
...
public:
static void no_close_flags(int f){no_close_flags_ = f;}
static int no_close_flags(){return no_close_flags_;}
private:
static int no_close_flags_;
};

The user can globally change the behaviour - ie at the beginning of the program when he changes the mask of no-closing items:

Fl_Menu_Item::no_close_flags(FL_MENU_TOGGLE|FL_MENU_RADIO|FL_SUBMENU|FL_SUBMENU_POINTER);

User can also control the items individually like:

#define FL_MENU_NO_CLOSE 0x200
Fl_Menu_Item::no_close_flags(FL_MENU_NO_CLOSE);

and then OR this custom flag to the other flags for particular menu items.

Post by Greg Ercolano
) {
#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..

It requires some small additional change in function Fl_Menu_::picked() (see submitted #2950) because some items (like checkbox/radio) may require to invoke
callbacks even if the menus are not closed but picking requires immediate response (either its own callback or parent-widget's one).

Anyway I have tested my implementation (which is more conservative - does not change default behaviour if you do not call Fl_Menu_Item::no_close_flags(int f), I
do not want to break users applications) and everything seems to work as expected.

Roman

[Roman Kantor]

Post by MacArthur, Ian (Selex ES, UK)

Post by Roman Kantor
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

Post by MacArthur, Ian (Selex ES, UK)

Post by Roman Kantor
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...).

Post by MacArthur, Ian (Selex ES, UK)
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.

Post by MacArthur, Ian (Selex ES, UK)
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.