Dynamic Toolbars

[adipose]

No description provided.

[clsid2]

Layout
I have been thinking about this a bit, and I am unsure if we should really allow to customize the order of the buttons. Maybe we should just keep it simple and only offer options to specify which (extra) buttons are shown. Could be a basic options page with a bunch of checkboxes. What do you think?

Button functionality
In MPC-BE some buttons have both a left-click and a right-click action. I think that would be a useful ability to reduce the amount of extra buttons we offer. A playlist button could for example have "toggle playlist" as left action, and "toggle shuffle" as right action. A fullscreen button could have "toggle fullscreen" as left, and "toggle minimal/normal mode" as right action.

Another useful ability is to show a small menu on click. For example with an "Subtitle" button that would show track selection and style options. Basically a specific subset of the main large menu.

We define the available buttons and the actions of each button. No customization for that. Again, just keep it simple. Let not waste a lot of effort on functionality that only a small group will use.

SVG for volume slider?
I also had an idea to integrate the volume slider into the toolbar SVG. Make it a two button wide image. The "enabled" button is a filled triangle, and the "disabled" button an empty triangle. Then based on the volume level we partially draw both images. Do you think that would be possible and look good? The code to handle the mouse clicks/drags on the volume part might be a bit tricky to implement. I think will potentially look very good, certainly when designers will use colors in the toolbar.

Next steps

1. Open issue to gather more feedback on which buttons/actions people need most.
2. Decide which ones we add.
3. Specify order of those buttons in the SVG. Use your 4 row layout.
4. Ask graphics designers to make a few toolbar images. I could do such a request maybe in changelog of a next release, so it gets a lot of exposure.
5. Pick a default SVG and replace current toolbar code. Initially it could be for just the current toolbar layout.
6. Implement extra buttons. Could be done one by one.

[adipose]

Layout I have been thinking about this a bit, and I am unsure if we should really allow to customize the order of the buttons. Maybe we should just keep it simple and only offer options to specify which (extra) buttons are shown. Could be a basic options page with a bunch of checkboxes. What do you think?

Well, it is designed to allow it, but that doesn't mean we have to build an interface for it. The checkboxes would surely be easier to design the GUI for. But we do have the shader gui which is a model for ordering / selecting options, so it's a possibility. If you want to customize your toolbar, chances are you care about the order, I guess, but being able to pick which ones are there is definitely 75% of it. Maybe groups as well--forward and back could be married, as it would be quite odd to separate them.

Button functionality In MPC-BE some buttons have both a left-click and a right-click action. I think that would be a useful ability to reduce the amount of extra buttons we offer. A playlist button could for example have "toggle playlist" as left action, and "toggle shuffle" as right action. A fullscreen button could have "toggle fullscreen" as left, and "toggle minimal/normal mode" as right action.

Assigning right click to a button is fine, in fact some defaults might go a long way there (fast forward, skip forward, for example). It would be a nice feature, but I wouldn't expect most users to discover it on their own. So probably nothing important should be defaulted to the right click, but it could be a place to "hide" a custom action the user wants to do without having to design new buttons.

Another useful ability is to show a small menu on click. For example with an "Subtitle" button that would show track selection and style options. Basically a specific subset of the main large menu.

Agreed, I plan to implement it.

We define the available buttons and the actions of each button. No customization for that. Again, just keep it simple. Let not waste a lot of effort on functionality that only a small group will use.

Agreed.

SVG for volume slider? I also had an idea to integrate the volume slider into the toolbar SVG. Make it a two button wide image. The "enabled" button is a filled triangle, and the "disabled" button an empty triangle. Then based on the volume level we partially draw both images. Do you think that would be possible and look good? The code to handle the mouse clicks/drags on the volume part might be a bit tricky to implement. I think will potentially look very good, certainly when designers will use colors in the toolbar.

I see what you are saying--it takes one position in the GUI but two in the SVG? Yes, I'm sure that would work fine for visual. But I assume we keep the actual volume slider, as a single button might not be wide enough to granularly select volume?

[clsid2]

Layout I have been thinking about this a bit, and I am unsure if we should really allow to customize the order of the buttons. Maybe we should just keep it simple and only offer options to specify which (extra) buttons are shown. Could be a basic options page with a bunch of checkboxes. What do you think?

Well, it is designed to allow it, but that doesn't mean we have to build an interface for it. The checkboxes would surely be easier to design the GUI for. But we do have the shader gui which is a model for ordering / selecting options, so it's a possibility. If you want to customize your toolbar, chances are you care about the order, I guess, but being able to pick which ones are there is definitely 75% of it. Maybe groups as well--forward and back could be married, as it would be quite odd to separate them.

Pairs of buttons could be a single checkbox in the new options GUI. For current buttons that would be "skip next/previous" and "speed increase/decrease". They will be placed next to each other then as well.

Button functionality In MPC-BE some buttons have both a left-click and a right-click action. I think that would be a useful ability to reduce the amount of extra buttons we offer. A playlist button could for example have "toggle playlist" as left action, and "toggle shuffle" as right action. A fullscreen button could have "toggle fullscreen" as left, and "toggle minimal/normal mode" as right action.

Assigning right click to a button is fine, in fact some defaults might go a long way there (fast forward, skip forward, for example). It would be a nice feature, but I wouldn't expect most users to discover it on their own. So probably nothing important should be defaulted to the right click, but it could be a place to "hide" a custom action the user wants to do without having to design new buttons.

MPC-BE shows both actions in the tooltip as left action | right action. I was thinking to do something similar, but maybe have too rows:

left:  action 1
right: action 2

SVG for volume slider? I also had an idea to integrate the volume slider into the toolbar SVG. Make it a two button wide image. The "enabled" button is a filled triangle, and the "disabled" button an empty triangle. Then based on the volume level we partially draw both images. Do you think that would be possible and look good? The code to handle the mouse clicks/drags on the volume part might be a bit tricky to implement. I think will potentially look very good, certainly when designers will use colors in the toolbar.

I see what you are saying--it takes one position in the GUI but two in the SVG? Yes, I'm sure that would work fine for visual. But I assume we keep the actual volume slider, as a single button might not be wide enough to granularly select volume?

To clarify I actually mean that the slider is too buttons wide. So if buttons are 24x24, then volume is 48x24 pixels, both in GUI and in SVG. It could even be wider if you think that is needed. That is just a matter of defining the content of the SVG.

So if volume is at 75%, we use the left 36 pixels of the "full" slider image, and the right 12 pixels of the "empty" slider images. That combined gives the 48 pixel wide image, which is visually filled at 75%.

[adipose]

I was working on this and it seemed pretty broken. It turns out when I restored patch194, I didn't restore from the most recent commit, but rather the original commit...that final commit appears to be gone from my local branch, but I merged in from the old pr which still remembers the commit I had proposed.

Seems ok again.