Driver using player, Unable to use shortcuts.

[nklerk]

With a driver that uses the player, its not posible to use shortcuts.
This is needed for things like switching audio profile, subtitle sellection, Eject, and other device specific options.

[pfiaux]

Currently we only have a full screen player, the plan is to make add a widget version of it which would be compatible with slides meaning there would be:

• regular widget slides
• player slide
• shortcuts

Would that work for your use case or do you have something different in mind?

[nklerk]

I'm not sure. different shortcuts are required depending on the users installation and needs.
So if the user can add thes like he can with normal drivers than that's all i need.

Besides that a Player builder would help i believe. this way the dev can enable/disable specific features of the player. like in my other request to have a STOP button. but other elements could be included as well like subtitles, audio channel etcetra.

Having shortcuts will resolve the need. the Plyer elements could make it all more pretty.

[pfiaux]

I think we're talking about the same thing, we consider the current player a full screen player and don't plan to add shortcuts there (scrolling up/down on a list and left/right to change slides would not be an ideal experience). However we also want to allow a non-fullscreen player widget which would work like a regular device with regular slides, one of which would be a player widget, and shortcuts would be available:

• Fullscreen player: Root directory + Player + Queue
• Regular player: Regular slides (with player widget) and shortcuts

In #118 we talked about the stop button for the player.

There's also #113 about documentation and making lists optional. We're already working on the optional lists and as part of the documentation we'll add a helper to add the player with a single function (similar to the button groups) and we'll allow the options in there, that should cover your builder concern.

[nklerk]

I personally prefer one interface, as in no difference. The fullscreen player could be one of the recipe pages.

I like the look and feel of the player. So ideally the rest of the UI would adopt that look and feel. Or the player addopt the “normal” UI.

This however is a totally different discussion.

The player is ideal for sonos. And I do understand this isn’t changed easily for other content types. Please try my kodi driver to experience this.

[nklerk]

This is what i more or less meant.
http://nielsdeklerk.nl/images/pi.png

Here with context:
http://nielsdeklerk.nl/images/pic.png

[nklerk]

Sorry, crappy GitHub, putting a close issue button where I expected a cancel.

Anyway.

The displayed buttons are options that can be enabled by the dev.

Player.displaySubtitleButton = true;
Player.displayStopButton = true;
Etc.

[pfiaux]

Nice, I like the mockups, thanks!

For adding stop we'll probably do something that looks similar in #118.

For integrating shortcuts/slides to the player (or the player to slides) it's much larger change. As you mentioned the player has it's origins with the Sonos screens. We're working on making it more flexible and integrating it but there's some changes behind the scene that need to happen first.
We also will need to decide internally if the player should look like slides or the other way around to keep the look and feel consistent, as you said that's a different discussion.

[carp3-noctem]

I would definitely prefer the player as a slide. That's the same as the list function, it makes sense to have it directly accessible as a slide and not as a shortcut button. I think I also allready requested this feature for the listviews. And definitely would like to have the same for the player. Also if you activate the player slide you can deactivate the control slide in most cases.

[nklerk]

As my expectations about the player component where wrong. I'll close the issue.