Option to hide Activate as secondary subs button

[Solarunit]

Option to hide Activate as secondary subs button in Subtitles menu.
I do not plan to use secondary subs but I am forced to see this button every time now.

[tomasklaen]

There are valid criticisms with current side buttons, like up & down in playlist are probably a bit too much, and actions shouldn't dangle outside menus when it's not necessary (hints/icon not that important to not be covered, like playlist), and I'm about to address that.

But your issues with footnote and secondary sub track button are way too nitpicky. These are both valuable features that don't affect the usability at all.

forced to see this button every time now

That's a bit melodramatic, isn't it? You can't expect every gui to have an option for each of its buttons to remove it when you don't plan to use it.

[dyphire]

like up & down in playlist are probably a bit too much

I think up & down in playlist are useful for pure mouse and touch operations and should not be removed.

[tomasklaen]

They are only useful if you want to move one item something like 1-2 positions away. Any other case is incredibly annoying to deal with, and would be more suited for drag and drop UX, which is something I'm not looking forward to implementing here, if ever...

I might re-add them back though if more people would want that.

[Sneakpeakcss]

They are only useful if you want to move one item something like 1-2 positions away. Any other case is incredibly annoying to deal with, and would be more suited for drag and drop UX, which is something I'm not looking forward to implementing here, if ever...

I might re-add them back though if more people would want that.

I don't see myself using this, but there's also the "select the button with right arrow and hold enter" use-case. A bit more convenient for moving entries without using both hands for modifier keys, especially when all the scrolling keys are in the same keyboard area.

However, it's a bit wonky because any mouse movement hides the buttons, and also resets the selection to the beginning of the playlist even when cursor is outside of the menu area.

[Solarunit]

That's a bit melodramatic, isn't it? You can't expect every gui to have an option for each of its buttons to remove it when you don't plan to use it.

Well, I think secondary sub track button looks cool but at the same time it makes menu looks less minimal like before, plus that hints/icon.

IMO secondary subs is a very niche feature and could be disabled by default.

[tomasklaen]

This kind of configuration granularity is a net negative because it introduces too much configuration fatigue for everyone trying to configure their players. Having to go through hundreds of options because there's one guy for every button who doesn't want to see it is not reasonable.

So sorry, but will have to be a wontfix.

[tomasklaen]

However, it's a bit wonky because any mouse movement hides the buttons, and also resets the selection

Yeah I found that annoying on several occasions as well, so the commit above changes the cursor selecting behavior in menus. The cursor will now never deselect any selected item. It can only select a different one, and even that filters out tiny cursor movements (1-10px) after periods of inactivity.

[dyphire]

However, it's a bit wonky because any mouse movement hides the buttons, and also resets the selection

Yeah I found that annoying on several occasions as well, so the commit above changes the cursor selecting behavior in menus. The cursor will now never deselect any selected item. It can only select a different one, and even that filters out tiny cursor movements (1-10px) after periods of inactivity.

The current behavior seems more confusing and inconvenient to me.
Now that the cursor is no longer released it means that these action buttons are visible whenever the menu is opened without any action being performed, which is really strange.

The buttons should be hidden when the cursor is released, and they shouldn't be shown by default until nothing is done.
I think filtering out some of the range of cursor movement is enough.

[tomasklaen]

buttons should be hidden , ...they shouldn't be shown by default until nothing is done

Can you provide some reasoning behind these statements instead of just stating them as absolutes? Without that these are just personal preferences of a change averse individual :).

The buttons show for the currently selected item, and that item is currently selected, so they're showing. If anything, they act as an additional selected item indicator.

Cursor not deselecting list/table row is actually a good UX. First time I encountered it was a long time ago when I noticed github doesn't remove active issue hover style when you mouse out. And I also found that strange and rolled my eyes. But after a while I found that quite useful as an indicator where I left off when changing windows.

Overall, cursor not deselecting items solves a lot of keyboard navigation issues and annoyances, provides an ability to visually "bookmark" stuff with cursor, and doesn't hurt anything. It's just a bit strange at first since you're not used to it. That's all.

[dyphire]

buttons should be hidden , ...they shouldn't be shown by default until nothing is done

Can you provide some reasoning behind these statements instead of just stating them as absolutes? Without that these are just personal preferences of a change averse individual :).

It's not a good idea to show action buttons by default when opening a menu, especially if the action buttons are outside the menu. When users only want to see track or playlist and file information and open the menu they will be distracted by buttons scattered inside and outside the menu. In the old behavior, users would open the menu to view the information without unnecessary interfering items, and the buttons would only appear when the user wanted to perform the operation to assist the user to use it more conveniently.

The default display of action buttons is beyond the presence they were meant to have, which is the same as #955. It should not be presupposed that the user open the menu only want to perform an action, perhaps just to view information.

The buttons show for the currently selected item, and that item is currently selected, so they're showing. If anything, they act as an additional selected item indicator.

When users only want to see track or playlist and file information and open the menu they will be distracted by buttons scattered inside and outside the menu

By the way, I can point out an obvious problem with the current behavior in this regard:

In testing, the current behavior of opening the menu to show the action button for the active item by default makes it impossible to view important hint information without taking additional action, which is not what I want.

Other opinions may be needed on whether or not to release the cursor after a cursor operation has already been performed in the menu, and I confirm that I see the benefit of not releasing the cursor, and am not adamant about it.

[Solarunit]

When users only want to see track or playlist and file information and open the menu they will be distracted by buttons scattered inside and outside the menu.

Yea, those buttons are a bit distracting

In the old behavior, users would open the menu to view the information without unnecessary interfering items

I often just open menu to check if the right audio track and subtitles selected at the beginning of the video

[Solarunit]

This kind of configuration granularity is a net negative because it introduces too much configuration fatigue for everyone trying to configure their players. Having to go through hundreds of options because there's one guy for every button who doesn't want to see it is not reasonable.

Yes, I see the problem with a huge config file, what about to change its format, maybe convert it to toml?
On the other hand I like that I can remove any button from the Controls bar, why not the same approach to the menus? Menus are important too 🙂

[Sneakpeakcss]

The default display of action buttons is beyond the presence they were meant to have, which is the same as #955. It should not be presupposed that the user open the menu only want to perform an action, perhaps just to view information.

Yeah, this is the gist of the issue that everyone has but describes in different way.

Not resetting the previous list selection is certainly a good thing, but keeping buttons constantly visible seems to go against the 'proximity-based out of mind out of sight' principle that uosc has by default.
The user can of course change the persistency for certain elements, but that's their own choice. Showing buttons when the user has no need for them feels out of place because it relies on the assumption that any time a menu is opened, they do it with the intention of using any of those actions. If they do not then it's simply a permanent clutter that they cannot avoid.

The most important thing that the buttons and tooltips added is function discovery without meddling in documentation and convenience, but the convenience part is currently a bit limited… For example, from what I can tell, only subtitle and file/playlist menus have buttons, and i personally cannot imagine any 'complex manipulation' happening in the former for the buttons to always be displayed, not to mention that 2 out of 3(delete) instantly close the menu after using them once.

In case of the playlist menu, we previously had arrow buttons, which enabled easier playlist manipulation with both mouse and keyboard. With mouse, their use was quite limited, but the keyboard had very high use potential that I mentioned above. The only thing that got in the way was the selection and buttons resetting after user already showed interest in using them at that moment.

Currently, with those buttons gone, we're left only with the delete button, which can be amusingly buggy:

delete.button.mp4

Its use with keyboard is far better, but at that point we can just press the delete key, so the only thing it offers is function discovery from the tooltip, which could very well be added to the footnotes.

As a btw, we have a few other annoyances now.

Potentially locking the tooltip in a visible state when the user never had any intention of using the buttons:

DOORSTUCK.mp4

Also, footnotes having their hover area over the whole menu width rather than the icon itself, which causes unnecessary flashes:

DOORSTUCK2.mp4

---

 

I can't speak for others, but for me the perfect scenario that avoids adding more config/visual bloat would be to:

• Move modifier/key notes from button tooltip to footnotes and at maximum only keep the function name to limit blocking the view like this:

  

  And if action is performed by button press then hide the tooltip while only keeping the button highlighted:

  This:
  

  Into this:

  

• Incorporate an impossible to miss button that toggles visibility of the function buttons. The most perfect result would be to place this button as part of the menu itself somewhere beside title at the top.
  This would avoid mistaking it with out of menu footnote icon, be as visible as possible and in best case scenario still able to select it with a TAB press during keyboard-only navigation (or just make it that even with button visibility turned off RIGHT arrow forces the visibilty + selection so keyboard-only navigation is completely seemless).

[tomasklaen]

keeping buttons constantly visible seems to go against the 'proximity-based out of mind out of sight' principle that uosc has by default.

This is a menu you see for a couple seconds when you need it. And you only see actions for currently selected item. This is not an issue.

Showing buttons when the user has no need for them feels out of place because it relies on the assumption that any time a menu is opened, they do it with the intention of using any of those actions. If they do not then it's simply a permanent clutter that they cannot avoid.

There's no API to tap into person's mind to determine if they're going to use a button when they're opening a menu. Making it configurable is not reasonable, as when you want it, you now have to go to your config file, restart, use it, and disable in config again?

not to mention that 2 out of 3(delete) instantly close the menu after using them once

I'm trying to establish a convention that only enter & exit should close the menu. Any other shortcut or press of a button should just do its thing without closing. I think all menus work like that atm. Let me know if I missed something.

In case of the playlist menu, we previously had arrow buttons

I added those back in, though other people pushed through reverting left/right buttons to submenu nagivation, so not sure how useful they are for one handed keyboard operation now. But I fixed them re-centering new index when activated with a pointer, which was unnecessary in pointer navigation.

delete button, which can be amusingly buggy

This should be fixed now. It was caused by an attempt to filter out small pointer movements from triggering item selection, but since pointer now won't deselect items anymore, this is not that necessary.

locking the tooltip in a visible state when the user never had any intention of using the buttons

Buttons are no longer retaining their selected state when pointer is moving. Only items.

Also, labels have been moved to footer, as I found them too distracting as tooltips.

footnotes having their hover area over the whole menu

Footnote trigger hitbox is now just the icon.

Incorporate an impossible to miss button that toggles visibility of the function buttons

Buttons to trigger other buttons is not gonna happen.

---

I hope the commits above address most of the issues. I think I've hit the best compromises I could. Still some minor things to hammer out, but I'm overall happy with how it works now.

[po5]

6b256b2: I'm not seeing these buttons.

[dyphire]

The buttons show for the currently selected item, and that item is currently selected, so they're showing. If anything, they act as an additional selected item indicator.

When users only want to see track or playlist and file information and open the menu they will be distracted by buttons scattered inside and outside the menu

By the way, I can point out an obvious problem with the current behavior in this regard: In testing, the current behavior of opening the menu to show the action button for the active item by default makes it impossible to view important hint information without taking additional action, which is not what I want.

The issue I raised remains unresolved.

[tomasklaen]

6b256b2: I'm not seeing these buttons.

That's a directory navigation menu you're in, not playlist. We can't sort directories :)

[tomasklaen]

The issue I raised remains unresolved.

Yes, that is a quite surprising and rare edge case. It's unexpected for track menus to have track names so long they cause menu to be so wide it forces actions inside. Track names should just describe a track, not be a {whole file name}.ass, that makes no sense.

Nevertheless, I'll try limiting menu's width to never force outside actions to be inside.

[tomasklaen]

Well, I guess not. Menu width is calculated loosely before it's rendered, and it would be too cumbersome to try duplicating and maintaining all action sizing and positioning in two places.

I think I'm fine with actions being forced inside in rare cases like this.

[dyphire]

Well, I guess not. Menu width is calculated loosely before it's rendered, and it would be too cumbersome to try duplicating and maintaining all action sizing and positioning in two places.

I think I'm fine with actions being forced inside in rare cases like this.

I'll be pushing a PR to try and optimize this extreme example of the track menu.

[po5]

That's a directory navigation menu you're in, not playlist. We can't sort directories :)

You're right, the "Playlist" button was showing my file in the directory instead of the playlist because there was only one file in my playlist.

[po5]

It's unexpected for track menus to have track names so long they cause menu to be so wide it forces actions inside.

If that's what it's supposed to be doing then the logic is very obviously wrong, this small menu has its actions inside:

[tomasklaen]

the logic is very obviously wrong

The logic is that actions are inside menus by default, as that is a bit more usable and nice.

But if a menu has a hint or icon that provides a higher than normal informational value, it has an option to ask menu to put the actions outside if possible.

This is currently only enabled for track menus, as their hints describe tracks and might contain language codes and such.

[Sneakpeakcss]

There's no API to tap into person's mind to determine if they're going to use a button when they're opening a menu. Making it configurable is not reasonable, as when you want it, you now have to go to your config file, restart, use it, and disable in config again?

Buttons to trigger other buttons is not gonna happen.

Obviously, there's no such API, and that's why this whole discussion revolves around making assumptions that are the least visually intrusive without adding more permanent persistency config options. At least, that's how I understood all of this.

Even if that visibility button was added, it would most likely end up with another discussion about the default visibility state and if it should persist between menus/menu closing. The button idea was more or less following the same logic as browser sidebar extensions with pin button. For a moment i thought about just having a hotkey for toggling the visibility at runtime, but that doesn't really help with anything. There's not much that can be done here besides changing when the buttons are shown based on region/element hovered or a toggle of some kind.

A random ending thought… Is it possible to use disable-elements on those buttons to have control over them through Lua?

I'm trying to establish a convention that only enter & exit should close the menu. Any other shortcut or press of a button should just do its thing without closing. I think all menus work like that atm. Let me know if I missed something.

From what i can tell, it works. Though, it would be better if someone who extensively uses the subtitle menu would chime in. Until the buttons were added i had that menu disabled since i didn't have any benefit from it while using context menus.

I added those back in, though other people pushed through reverting left/right buttons to submenu nagivation, so not sure how useful they are for one handed keyboard operation now. But I fixed them re-centering new index when activated with a pointer, which was unnecessary in pointer navigation.

Far less useful for one-handed, but still a viable option (avoids holding the modifier key all the time). I'm myself on the side that arrow keys should be kept as submenu navigation because switching between arrows/enter/backspace was just tedious. If it's possible to allow LEFT/RIGHT to move between action buttons after they were selected with TAB, then this would be the best of both worlds. However, when it comes to the mouse…

KBvsM.mp4

Looks like we got that toggle button after all lol. Its use is mostly for minimal reordering before someone gets annoyed and switches to kb.

Buttons are no longer retaining their selected state when pointer is moving. Only items.

This looks perfect now.

Also, labels have been moved to footer, as I found them too distracting as tooltips.

Footnote trigger hitbox is now just the icon.

Ooh, fancy. This is really good now and is also a good example of what i meant about keeping the visuals limited as much as possible until we can no longer make assumptions. There's no unnecessary permanent clutter, the note position is kept in one very visible place that doesn't obstruct anything else, and it is only shown when we can no longer assume that the user didn't want to use it. The only improvement i can think of is to add a small delay, so fast mouse movements over those elements do not flash the notes, but that's mostly nitpicky to completely limit any accidental flashes.

I hope the commits above address most of the issues. I think I've hit the best compromises I could. Still some minor things to hammer out, but I'm overall happy with how it works now.

Yea, i found some potential bugs with subs reload, but since I never used it before, i don't know if this is connected to recent changes. I'll make a separate issue for this, so you don't have to reference comments in unrelated topic again since we kinda hijacked this and made it a general discussion thing.