Re: [fltk.general] Menu behaviour...
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.
On 09/04/2013 17:26, Greg Ercolano wrote:
) {
#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
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Menu behaviour...
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
Re: [fltk.general] Menu behaviour...
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
