Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
I have put the functions in Fl_Menu_Item namespace only because maming them that way seems to make sense. As far as I know, static functions (and static class variables) do not break ABI: they are not really class members, just additional ordinary functions and global variables with fancy naming sugar (functions with class namespace scope). For that matter even addition of a non-virtual class function should not break ABI either - any compiler guru can confirm this or am I wrong? I'm in favour of this change, if we are happy it's not ABI breaking. I'm not even sure, but Roman's discussion sounds right! 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. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature Roman, this looks like a good idea, I recommend adding it, however with two caveats. I'll post them in followup messages. WRT ABI issues: adding flags and static methods doesn't break the ABI, so we should be safe here. Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature #2: I believe that the following part of this proposal should not be added as given: change code in function Fl_Menu_::picked() from line approx 271: ... else if(!(value_-flags Fl_Menu_Item::no_close_flags() (FL_SUBMENU | FL_SUBMENU_POINTER))) // do not execute parent's widget (common) callback if there is no direct menuitem callback assigned // and menu is not closed and isem is just a submenu (no valid item picked) do_callback(); } It think that not calling a callback for submenus is unrelated to the option not to close the menu when the item is clicked on. What if someone wants a callback when a submenu is clicked on, but doesn't want the menu to be closed? Setting the FL_MENU_NOCLOSE flag would prevent the callback from being called in this situation, if I understand correctly what is going on here. I don't really know why one would want a callback to be called when a submenu gets selected, but I can imagine that you could change the submenu before it is popped up (or popup()ed? ;-)). Also, I believe the code could be changed to be more clear, but maybe you did it as proposed because you had compatibility in mind. Wouldn't something like this be better? if ( !((value_-flags Fl_Menu_Item::no_close_flags()) (FL_SUBMENU | FL_SUBMENU_POINTER)) ) Well, I really don't grok it entirely now, but I hope you got my idea. This should be discussed further, and maybe a test programm would be fine. Roman, could you post one and describe a procedure to test what you want to achieve, so that we can see the effect when implementing it? Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Albrecht,
1) To have global function (although as static in Fl_Menu_Item)
no_close_flags(int f) is to allow user simply to change begaviour globally
for isntance for all submenus by calling
Fl_Menu_Item::no_close_flags(FL_SUBMENU|FL_SUBMENU_POINTER);
Then it woult not be required to set any menuitem flag explicitly, so all
code (for instance fluid generated) would work with new behaviour as
expected
2) I an not against adding an extra FL_MENU_NOCLOSE enumeration flag, just
showing that this is unnecessary as it can be done by the user. Having
function no_close_flags() allows to control behaviour BOTH globaly and in
per-item fasion. But adding FL_MENU_NOCLOSE to api and setting by default
static int no_close_flags_ = FL_MENU_NOCLOSE;
or even to
static int no_close_flags_ = FL_MENU_NOCLOSE | FL_SUBMENU |
FL_SUBMENU_POINTER;
// breaks backward compatibility
is fine with me, although the second one breaks backward compatibility
3)
Your code
if ( !((value_-flags Fl_Menu_Item::no_close_flags()) (FL_SUBMENU |
FL_SUBMENU_POINTER)) )
does not make sense to me - second part (FL_SUBMENU |
FL_SUBMENU_POINTER) is a constant expression and is always true.
The code change as proposed is to assure strict backward compatibility:
submenus until now never called widget common callback (even when menu
is closed) with submenu-item picked. This is to avoid calling this
callback with wrong item picked - which can not be selected for instance
Fl_Choice with submenu (you can not set this Fl_Choice to the state with
submenu-item picked). However new code would indicate submenu-item as
picked during callback and could even crash a program if the program
relies that only ordinary items can be selected. The user still can assign
a callbback directly to submenu-item if he wishes so (probably a rare
case).
And yes, this is a real-life case: without the change one of my
applications with Fl_Choice with submenus crashed.
3) I would propose to have functions no_close_flags() NOT inlined to avoid
initialization fiasco (if somebody would call this before main() or some
crazy pal would call gui before main()), I would implement them in
Fl_Menu.cxx as
static int menu_no_close_flags_ = FL_MENU_NOCLOSE;
void Fl_Meu_Item::no_close_flags(int m){return menu_no_close_flags_ = m;}
int Fl_Meu_Item::no_close_flags(){return menu_no_close_flags_;}
Roman
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Ops, the second line from the bottom should be of course without return:
void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ = m;}
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Roman,
1) I didn't write that I didn't want that global flag, and I understood
what you wanted to achieve with it. That's all okay so far.
2) It was not the point that adding a new flag is unnecessary as it can
be done by the user. My point is: we should *avoid* to make the user set
any flags in the menu items except those that are defined in the library.
One argument is to be free to define other bits for new use cases within
the library w/o risking damage if a user defined exactly this bit for his
purposes (as it would be possible with your primary proposal). Therefore I
am for adding this extra bit to the enumeration within the library. Only
that was the reason to do it like Greg proposed, everything else just like
your proposal would be okay with me.
3) Yes, you're right, my code was bad - I was in a hurry. But I still
believe that the callback issue is another issue unrelated to the no_close
flag, so this shouldn't be mixed. However, I don't have the time to think
further about it now, so I'll post later regarding this.
4) to your new code proposals: okay with one exception: if we use the
FL_MENU_NOCLOSE flag, then it would be handy to change this one:
void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ =
m|FL_MENU_NOCLOSE;}
so that FL_MENU_NOCLOSE will always be set in the flags for testing.
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
We can probably avoid breaking ABI if we implement this new bitflag
as part of the existing flags, eg:
enum { // values for flags:
:
FL_MENU_NOCLOSE = 0x200 // Don't close menu if submenu|checkbox
clicked
};
Unless I'm missing something, is there a reason to avoid this?
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature Oh, I see, you are suggesting this, /and/ a global flag to affect the entire menu, yes. I guess we can't avoid breaking ABI for the global flag, which is probably best implemented in Fl_Menu_ by adding an int to the class, protected by our new ABI macro so it can be used during patch releases) Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature I have put the functions in Fl_Menu_Item namespace only because maming them that way seems to make sense. As far as I know, static functions (and static class variables) do not break ABI: they are not really class members, just additional ordinary functions and global variables with fancy naming sugar (functions with class namespace scope). For that matter even addition of a non-virtual class function should not break ABI either - any compiler guru can confirm this or am I wrong? Anyway, the function is to set a mask which menu-item flags should indicate not to close the menu. In that way an existing application could take advantage of new behaviour automatically (especially those pesky submenu items) just by adding simple Fl_Menu_Item::no_close_flags(FL_MENU_TOGGLE|FL_MENU_RADIO|FL_SUBMENU|FL_SUBMENU_POINTER); or whatever flags you want at the beginning of the program. But if the user wants old behaviour and set only a few items explicitly, he can always define his own flag and set Fl_Menu_Item::no_close_flags(...) mask to this custom flag only. R. Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
