Ticket #3160 (new defect)
Dialog hotfocus color misused in listbox
Reported by: | egmont | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Future Releases |
Component: | mc-skin | Version: | 4.8.11 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #3169 | |
Branch state: | no branch | Votes for changeset: |
Description
The highlighted item in listboxes use DLG_COLOR_HOT_FOCUS if the widget is focused, and DLG_COLOR_FOCUS if the widget is not focused.
This is clearly a misuse of the semantics. "Hot" is supposed to stand for hotkey (aka. shortcut key) color, a single character within a string. This feature is unused in listboxes. Using the hotkey color for the whole line makes it underlined in the "sand256" skin which was not intended there. In #2165 I'm working on a config option to use underline for hotkeys with any skin, this bug is blocking that.
I'm not sure if making a distinction whether the widget is focused or not is important, I don't think so. How can a listbox widget be unfocused at all? If it can be, isn't it obvious by other means (e.g. other window overlapping it?)
I think the right approach is to always use DLG_COLOR_FOCUS. (In this case there's still a confusion that what is called "focused" in the skin definiton is "selected" in the source, and "focused" in the source means something totally different.)
The patch also fixes the "sand256" skin, it used to have an explicit underline for popup boxes (e.g. F2 user menu) to make it consistent with the broken listbox (e.g. Alt+H history), it's now removed, from now on underline is used solely for hotkeys in this skin.
Attachments
Change History
comment:1 in reply to: ↑ description Changed 11 years ago by andrew_b
comment:2 Changed 11 years ago by egmont
Geez I didn't remember I had submitted similar issues before :) I also didn't know how to make a listbox unfocused (I don't use those features of mc), now I know, thanks.
It's important to keep the selected entry highlighted on focus out. E.g. in the "find file" results you'd navigate with TAB to "View" and by that time you wouldn't be sure which file you are going to see.
I think we should fork a color or two. A bit of a problem is that there's "dfocus" which should be the normal color for focused, and "dhotfocus" is supposed to be more prominent than that. So listboxes use "dhotfocus" by default so that they can go back in intensity to "dfocus" when unfocused. It's inconsistent in the default skin that the normal selected color in config dialogs is "black on cyan", but on listboxes it's "blue on cyan" for this reason. A good skin would, in my opinion, would use three colors: one for selected entries in dialogs and in listboxes, one more prominent for hotkey, and one less prominent for unfocused selected listbox entries. But such a change would force a change in the current skins, two colors that are different now (e.g. selected checkbox vs selected on focused listbox) would be forced to be the same. I'm not confident making such a change for all skins.
My suggestion is hence to introduce two new variables: one for focused listbox's selected entry (forked from dhotfocus) and one for unfocused listbox's selected entry (forked from dfocus). This is just a mechanical copy-paste in skins so that they maintain the exact same look.
comment:5 Changed 3 years ago by andrew_b
Ticket #4274 has been marked as a duplicate of this ticket.
comment:6 Changed 21 months ago by proski
dhotfocus is for the hotkey, a single letter that should stand out in a label. It is also supposed to be readable, but readability of the remaining text is more important than readability of a single letter. Using dhotfocus for whole lines of text is bad for readability, it turns the whole text into a hotkey. It also confuses and limits theme authors, who have to choose a color that won't look too bad in listboxes.
In particular, I changed the julia256 theme to show hotkeys in red (both focused and unfocused), which was a nice improvement. I have to deal with whole likes in red on cyan in search results. It's readable, but it's not an improvement at all. I'm even considering another patch to make focused hotkeys black (essentially hiding them while focused) to have better looking listboxes.
Replying to egmont:
This feature is not implemented in listboxes. For example, listbox is the base widget for user menu (remember #2171). Hotkeys could be useful in it. Also hotkeys could be useful in "Directory hotlist" (#2672).
What do you mean "ar all"? Widget can be focused or not. Even widgets are not overlapped, one of dialog widgets is focused, others aren't. Look at "Directory hotlist" or "Find File" results window. When button gets focus, hotlist became unfocused. May be, do not highlight current line in listbox if listbox is unfocused?