Menu behavior bugs

[nyanpasu64]

Child menus steal focus when opening

If you open a child menu, the child menu's first item is colored with focus even if the mouse isn't hovering it. When the mouse next moves, the child menu loses focus color. (If the mouse is moving quickly, the child menu flickers purple then white.)

Closing child menus causes parent to steal focus

When a child menu closes on a timer, it causes its parent to gain focus, and the menu item under the mouse to lose the focus color until your mouse next moves. If your mouse is moving, it shows up as a flash of white as the item loses focus and immediately gains it back.

Cannot close menus by clicking outside of window

See heading.

Cannot close menus by clicking on menu bar

See heading.

kas.menu.bugs.mp4

Also are the wgpu errors on startup known? I copied the logs to a gist (link).

[dhardy]

Child menus steal focus when opening

This is intentional for keyboard navigation but as you say, it shouldn't happen when using the mouse to open sub-menus.

Other menu behaviour bugs: agreed.

[2021-09-30T08:01:49Z ERROR wgpu_core::validation] Unexpected varying type: Array { base: [1], size: Constant([5]), stride: 4 }

Known, yes. It sounds similar to gfx-rs/wgpu#1427 but I didn't put much effort into investigating this.

[nyanpasu64]

Honestly it's encouraging that you're considering behavior like tab navigation and keyboard-operated menus (and right-to-left/complex text layout) early on. They're aspects often neglected in mobile/embedded (touch-based) frameworks like SixtyFPS (Flutter?) or game-oriented UI frameworks like immediate-mode GUIs.

[dhardy]

I think KAS may have been the first Rust GUI with any significant keyboard navigation; it was a part of the design from quite early on (it may be a little easier with retained widgets). Touch support too, though that's still fairly limited (the Mandlebrot demo has two-finger rotation/pan/scaling and there's some attempt to make touch selection/panning work).