You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using fvwm3 1.0.6a (released) built from AUR on Arch Linux, I see an aesthetic glitch on Fvwm menus: in the currently highlighted/selected menu item, the underline below the hotkey character stays with the default foreground color instead of assuming the foreground color for highlighted menu items.
E.g., in the example attached, the default menu items are black on white and the highlighted menu items are white on red. The text in the highlighted menu item ("Maximize x") is white on red (as it should), but the underline below the final "x" is black on red instead of white on red.
I realize that this is not a bug technically speaking (the program works correctly), but I do think this is an aesthetic glitch. I think that all Gtk applications have the hotkey underline assuming the current text color; and so does Openbox, for example.
The text was updated successfully, but these errors were encountered:
Hi Thomas,
Obviously you are the one who knows about the source code, but I was a bit
puzzled by your reply. Isn't "redrawing the menu item every time an item is
highlighted" what fvwm is doing anyway when the colorsets for highlighted
and default items differ?
By the way, you may have seen that I am a new subscriber to the fvwm forum.
I am almost done with my fwmrc, and I will soon send appreciation comments
to the list. Fvwm is just ... amazing. Nothing can compare!
Best,
François
On Sat, Sep 2, 2023 at 9:07 AM Thomas Adam ***@***.***> wrote:
Hi @ftonneau <https://github.com/ftonneau>
To "fix" this, we would have to redraw the menu item every time an item
was highlighted. This would not be a good thing to do.
I am not sure it's worth considering, so I'm going to close this report,
but thanks for sending it through anyway.
—
Reply to this email directly, view it on GitHub
<#894 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANCNKJ2CP3PZVKW6CYNWW4LXYMOPZANCNFSM6AAAAAA4GR3DCE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
Heh -- you're right that highlighting does redraw (XClearRegion()) the item, but what I was saying by redraw is to re-render the text of the menu, which would look very weird, and ultimately would cause visual glitches as it was redrawing.
I understand that the region (= the background) is redrawn, but so does the text (= foreground) in my example, as the highlighted text is white whereas the default text is black. Anyway, to get rid of the underline color discrepancy I now use the same text color for highlighted and default menu items, with good results :-)
Using fvwm3 1.0.6a (released) built from AUR on Arch Linux, I see an aesthetic glitch on Fvwm menus: in the currently highlighted/selected menu item, the underline below the hotkey character stays with the default foreground color instead of assuming the foreground color for highlighted menu items.
E.g., in the example attached, the default menu items are black on white and the highlighted menu items are white on red. The text in the highlighted menu item ("Maximize x") is white on red (as it should), but the underline below the final "x" is black on red instead of white on red.
I realize that this is not a bug technically speaking (the program works correctly), but I do think this is an aesthetic glitch. I think that all Gtk applications have the hotkey underline assuming the current text color; and so does Openbox, for example.
The text was updated successfully, but these errors were encountered: