Menu navigation in FLTK is different from Ubuntu X11 navigation

[Brian Larsen]

I'm using FLTK 1.4 master on Ubuntu X11. The menu navigation in apps built
with FLTK is different from the native apps.

For the native apps using the left/right/up/down arrows on a menu will wrap.
For example, using left arrow on a menu bar moves from the leftmost menu item
to the rightmost menu item; similarly on a popup menu using down arrow moves
from the bottom item to the top item.

For an FLTK app, including the examples, no wrap occurs.

This seems like a simple fix, but the comments in Fl_Menu.cxx indicate
there is a some complex history involving handle_part1() and handle_part2(),
so I wouldn't be surprised if no one really wants to mess with that part
of the code.

In my app can I just sub-class menuwindow and override handle() or is it
more complicated? For example, if I'm using Fl_Sys_Menu_Bar, do I also have
to sub-class that too and then tell it to use my subclass of menuwindow?

[Manolo]

Le lundi 24 juin 2024 à 07:07:43 UTC+2, Brian Larsen a écrit :

I'm using FLTK 1.4 master on Ubuntu X11. The menu navigation in apps built
with FLTK is different from the native apps.

For the native apps using the left/right/up/down arrows on a menu will wrap.
……

For an FLTK app, including the examples, no wrap occurs.

This seems like a simple fix, but the comments in Fl_Menu.cxx indicate
there is a some complex history involving handle_part1() and handle_part2(),
so I wouldn't be surprised if no one really wants to mess with that part
of the code.

In my app can I just sub-class menuwindow and override handle() or is it
more complicated? For example, if I'm using Fl_Sys_Menu_Bar, do I also have
to sub-class that too and then tell it to use my subclass of menuwindow?

Overriding Fl_Menu_Bar::handle() is probably enough to obtain the desired

menu wrapping. The new Fl_Menu_Bar::play_menu(const Fl_Menu_Item*)  

member function might be helpful.

As for Fl_Sys_Menu_Bar, nothing special should be needed because under

macOS, the wrap is already in place.

If you succeed, please, post your solution here, we might push it to git.

[Manolo]

On 24 juin 2024 à 08:30:57 UTC+2, Manolo wrote :

Overriding Fl_Menu_Bar::handle() is probably enough to obtain the desired

menu wrapping.

 Looking closer, this might be more complicated than overriding Fl_Menu_Bar::handle().

[Brian Larsen]

OK, I'll try a few experiments, if I find a solution I'll let you know. Meanwhile if you have any new

ideas let me know.

[Manolo]

Le lundi 24 juin 2024 à 10:27:06 UTC+2, Brian Larsen a écrit :

OK, I'll try a few experiments, if I find a solution I'll let you know. Meanwhile if you have any new

ideas let me know.

I've decided to implement it. It's committed to FLTK 1.4 at c1a950e

 

[Brian Larsen]

Wow, you're awesome. I spent a couple hours trying things and I only had partial success,

mainly because it was a hard to understand how the menu vs menubar worked and my 

changes were in handle_part1() instead of in forware() and backward() . At least I learned

something by seeing how you fixed this.  

I just tested your fix and it works except when a  sub-menu of the menu bar has only 1 item.

I've attached a patch that fixes that for me, hopefully it works for all cases.

[Manolo]

Le lundi 24 juin 2024 à 17:00:09 UTC+2, Brian Larsen a écrit :

I just tested your fix and it works except when a  sub-menu of the menu bar has only 1 item.

I've attached a patch that fixes that for me, hopefully it works for all cases.

There were still some border cases with your patch. A new commit (fe4c94b) should handle

all cases correctly.

 

[Brian Larsen]

Unfortunately with commit fe4c94b some case that were working with your previous fix no longer
work. Here are the working and not working cases I noticed

1) If the selected menu item is on the menu *bar* then most (all?) cases appear to work as before.
2) Up/Down arrow does not wrap at all now.
3) If the selected menu item is in a sub-menu, Left arrow still wraps as before.
4) If the selected menu item is in a sub-menu, Right arrow no longer wraps. (Go to the right most menu bar item and move down into that sub-menu, right arrow does nothing)

[Ian MacArthur]

FWIW, I'm uneasy about sweating this one too much...

I did some random tests on various other systems, with assorted WM and toolkits, and the results have been somewhat... variable, might be the best thing to say.

I'm left with the feeling that there's no "right" way to do this, as different tools seem to exhibit different behaviour. 

And, as far as it goes, I have the impression that most folks don't even notice anyway!

[Albrecht Schlosser]

I agree with Ian, and I didn't see mention of Windows in this thread yet. What is the Windows behavior WRT wrapping menus?

More thoughts: we need to decide which part of FLTK is its own behavior - across platforms - and which part is different on specific platforms.

So far ISTR that all related commits were in platform independent parts, thus we can say that this is FLTK specific behavior. Whether this should be changed in any way to be closer to *any* other platform I cannot say.

If it is too difficult to change (as it seems) my vote would be to revert all the attempted fixes to the original code which is presumably the behavior we have in FLTK 1.3 anyway. Otherwise someone could complain that the new behavior is a regression.

Note also that there was mention of a new menu system in FLTK 1.5, likely based on Fl_Widget's etc.. This would be the time to rethink menu behavior based on the "new" menus.

(Just my 2 ct as a reader and user, not an "official" statement.)

[Brian Larsen]

That's understandable and reasonable and it sounds like it's too easy to get unexpected side effects when making changes

in this area. At the moment I'm happy locally keeping commit c1a950e plus my patch as it works well for my case. If you guys 

want to revert either or both commits related to this that's fine with me.

[Ian MacArthur]

On Tuesday 25 June 2024 at 13:49:44 UTC+1 Albrecht-S wrote:

I agree with Ian, and I didn't see mention of Windows in this thread yet. What is the Windows behavior WRT wrapping menus?

So, Windows...

Well, that kinda depends.

I tried a few random "Windows native" apps first, on Windows 10, and they all behaved "quite a lot" like my Ubuntu laptop, which TBH I was surprised about since I didn't think the Windows menu system supported wrapping (indeed, I had a strong but apparently false memory that it did not.)

Then later on I was using Outlook (app not web) and found that it appears to grab the cursor keys for it's own nefarious ends so the navigation on the "ribbon" did not seem to work in the same way as I'd seen with more "classical" Windows apps. Subsequent testing, particularly with MS own apps, exposed a "variety" of behaviours. So I don't think there's a standard, or if there is it is not widely followed.

I also tried Win11, but can't actually remember now what behaviour I saw!

Different *nix WM's seem to have varying opinions on this too, of course.

FWIW, I do not think the changes Manolo has made necessarily need to be reverted - they are no "worse" than what we had, are arguably better in some edge cases, and in any case I suspect most users will never notice the changed behaviour anyway (for the general case it still behaves "much as before".)

[Albrecht Schlosser]

On 6/25/24 15:08 Ian MacArthur wrote:
>
> FWIW, I do not think the changes Manolo has made necessarily need to
> be reverted - they are no "worse" than what we had, are arguably
> better in some edge cases, and in any case I suspect most users will
> never notice the changed behaviour anyway (for the general case it
> still behaves "much as before".)

I'd be fine with any change, as long as it will not widely be considered
a regression.

Personally I don't care much about menu wrapping behavior anyway. If you
had asked me before this discussion I would probably have voted against
wrapping. Imagine the "Huge" menu in test/menubar would wrap when you
hold the Down key pressed until it reaches the end... ;-)

[Brian Larsen]

I realize that possibly not many people care about this, but since I
made more changes that work better and more consistently on my Ubuntu
with X11 system I might as well share them.

If Manolo (or someone) has enough patience and/or interest left to take
another look that would be great. If not that's fine too, at least I
have something that seems useful to me.

I believe all the arrow keys, TAB and Shift-TAB work more consistently
now including in the menu specific programs under examples/ and test/.

One thing to note about the attached patch; it reverts the last commit
by Manolo (fe4c94b4d) and restores the first commit (c1a950e25) because
that worked better for me. That might mean that some corner cases that
Manolo saw, will be present again... it depends what those cases were
and whether or not my new changes address them.

The rest of the changes are in menuwindow::handle_part1().

Finally, if no one is really interested in this I won't bug everyone
with more comments on the subject :)

[Manolo]

I try to solve this thread with commit b692cc5.

About wrapping to the other side of the menubar when hitting left/right arrow:

- macOS app with their system menubar do that;

- gnome and Windows apps equipped with a menubar also do that;

- therefore FLTK apps will now do that too;

- other slight change in Fl_Menu_Bar: the arrow key is also active when a submenu

is open.

About wrapping to the other end of a menu with up/down arrows:

- gnome (synaptic, cmake-gui) and Windows apps (cmake-gui, Notepad++) equipped 

with a menubar do that;

- but macOS apps don't;

- I agree with Albrecht that this behavior is not convenient with long menus;

- class Fl_Menu_Bar allows that already with the Tab key;

- therefore FLTK was not changed in this aspect.

[Brian Larsen]

Thanks for spending more time on this. Commit b692cc5 makes navigating menus in 

FLTK much more consistent and intuitive; the left/right arrows have opposite effects 

and the up/down arrows have opposite effects. I wish it had wrapping in all cases, but

the current functionality is very nice.

The only inconsistent thing I noticed is with TAB and SHIFT+TAB.                                                        
- TAB appears to always act as down arrow (plus it allows wrapping).

- SHIFT+TAB in the menubar acts as left arrow without wrapping.

- SHIFT+TAB in a normal menu acts as up arrow, but if that menu is
  a sub-menu of a menubar it stops at the top element of the menu
  instead of moving to the menu bar like up arrow does.
  Also in this case if you are at the top menu item and use SHIFT+TAB
  then you must press TAB twice before the selection changes. You

  can see this in the test programs, e.g. examples/table-with-right-click-menu and test/menubar.

[Brian Larsen]

Is there any interest in having full wrapping as an option? 

menu3.patch allows this using the #define MENU_UP_DOWN_WRAP, which 

should probably be converted into an API call *if* it became part of FLTK.

Setting MENU_UP_DOWN_WRAP to 0 and rebuilding gives the same current
functionality (as in commit b692cc5).

Setting MENU_UP_DOWN_WRAP to 1 and rebuilding allows the up/down arrows
to wrap (the way I like).