Separator in menu gets focus
Closed this issue · 11 comments
Upfront Information
-
Fvwm3 version (run:
fvwm3 --version)
fvwm3 1.0.5 (1.0.4-128-gc7b41a03) with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS -
Linux distribution or BSD name/version
Arch Linux -
Platform (run:
uname -sp)
Linux 5.15.53-1-lts #1 SMP x86_64 GNU/Linux
Expected Behaviour
Using arrow keys on keyboard to move through a menu should not focus separators/delimiters (+ "" Nop items). In FVWM2 separators did not get focus, but in recent git FVWM3 they do get focus.
Actual Behaviour
Separators get focus as if they were regular menu items. But they should not get any focus.
Enabling logging
N/A
Steps to Reproduce
Create menu:
DestroyMenu FvwmRootMenu
AddToMenu FvwmRootMenu
+ "$[gt.Console]%terminal%" Exec exec xterm
+ "" Nop
+ "$[gt.Console2]%terminal%" Exec exec xterm
- Does the problem also happen with Fvwm2?
No.
Does Fvwm3 crash?
No
Extra Information
Some real menus look then like this (the top separator is focused by arrow selection and the bottom one is not focused):
(note the color style is chosen deliberately so that one can recognize which colors are being used for what part of the frame(s))
Not a fvwm problem. I'm going to guess it's a graphics driver problem.
Oh, this is a misunderstanding. With "focus" I am exclusively referring to keyboard focus, not any visual focus. In the following menu:
DestroyMenu FvwmRootMenu
AddToMenu FvwmRootMenu
+ "$[gt.Console]%terminal%" Exec exec xterm
+ "" Nop
+ "$[gt.Console2]%terminal%" Exec exec xterm
If I focus Console by keyboard arrows and then press the "down arrow" key on the keyboard it will not focus Console2 item in fvwm3 but rather the tiny "Nop" separator line. In fvwm2 doing the same does focus Console2.
This has really nothing to do with any graphics driver.
I can confirm this as well, when using the keyboard to move through window items in a menu, it will hit the Nop separators, and require a second key press to move to the item below the separator. This is a "recent" change, as it worked as expected in 1.0.4, but a rebuild of current master the bug shows up. So something has changed since 1.0.4.
Yes indeed. Thanks for the tip about using the keyboard.
After a little dance with git-bisect, this breakage was introduced in 91ef704
I am not too sure why this only happens with the menu. A proposed change might be the following:
diff --git a/fvwm/menuitem.c b/fvwm/menuitem.c
index beeea336e..34f186d9a 100644
--- a/fvwm/menuitem.c
+++ b/fvwm/menuitem.c
@@ -461,7 +461,8 @@ void menuitem_paint(
}
else
{
- MI_IS_SELECTABLE(mi) = True;
+ if (!MI_IS_SEPARATOR(mi))
+ MI_IS_SELECTABLE(mi) = True;
gcs = ST_MENU_INACTIVE_GCS(ms);
off_gcs = ST_MENU_INACTIVE_GCS(ms);
}@topcat001 -- can you check if the above doesn't break the intent of your original change?
@somiaj / @dumblob -- if you could test the above patch, regardless of anything else, I'd appreciate it.
Aha! I missed this case because I don't usually use the keyboard to navigate menus. Thanks! I'll test this and report back. Fairly sure this fixes it.
@ThomasAdam works for me. Thanks!
This fixes the issue here. Side comment, I do notice if you mouse over the separator exactly, both the item above and below lose focus, but the separator isn't gaining focus and the keyboard movement looks like what is expected (fixing the actual issue).
I never looked at what the original commit was suppose to fix/change, just stating that this fixes this issue with the keyboard movement, and what I noticed with mousing over a separator.
Seems to work for me - I use keyboard exclusively to navigate menus. I did not test (read compare to fvwm2) mouse behavior as that is not priority for me 😉 - but if you insisted, I will test the mouse behavior too.