My reason for requesting this is simply as a convenience for the way I construct menus. It is not uncommon for me do a bit more convoluted coding than I would prefer, thanks to arranging for a divider that requires the flag on the preceding item instead of the current item. The implementation logic I use to build a menu is append-to-list-oriented and its context ideally should be limited in scope to the single item at hand, not to the preceding item in addition. Moreover, it is common for me to have to re-build my menus dynamically based on changing program state. Thus, it would suit my implementation logic better if I could just stay with the append concept in the current context, whether for an item or a divider.

Actually, your point no. 5 (new Fl_Men_Item-derived class that just draws a divider) sounds to me like a good idea. However, there would still need to be a special character that can be used to specify it when using the very handy string-oriented method Fl_Menu::add(const char*), which is something I also utilize a lot. As for that special character, I understand and agree with all the points you made and would be happy with whatever character and config-time enabling you think best.

But maybe there is an alternative to a new special character. As you know, using just the character sequence '|_' (which I tried early on in my programming with FLTK) results in a menu item with no text, which nevertheless occupies space in the menu (blank) as any other item and therefore looks inappropriate. Perhaps '|_' should be interpreted as a special case that just inserts the divider (maybe an instance of your new divider-only item class) without the blank space. My guess is that the risk to breaking existing code with this approach is small, since I would be surprised if many (any) programmers actually want the effect of a blank menu item with a divider under it.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/479/1214212857@github.com>