Media Player should not be visible in the app scope and launcher

I don't think there's anything to do in unity8, it should be enough to go "NoDisplay=True" or similar in the .desktop file for the mediaplayer app.

Maybe the NoDisplay=true has changed since the last time I tried it, but when I tried to fix this bug in the past, adding that tag to the desktop file meant that the mediaplayer-app wouldn't launch anymore.

Yeah, url-dispatcher seems to ignore apps with "NoDisplay=true". Workaround is to go "OnlyShowIn=Old" for now.

Adding a url-dispatcher task in any case.

Awesome, thanks for the reply! It'll be great to get this simple bug fixed.

I'm a little confused here. It seems like media player should be using a trusted prompt session instead of a desktop file. That seems to handle the design requirements better.

Where is the rationale for this?

Can we please have bugs filed where they state a problem, and not a description of a task the reporter expects developers to do? And if the problem is related to design, please provide the appropriate links to rationale of why the design is changed, so that the developers can understand things better.

What's the status of this fix landing for vivid/rtm?

Status changed to 'Confirmed' because the bug affects multiple users.

I agree with Ted, if the media player should never "be" an app, it needs to be a trusted prompt, overlaying the originating app, not its own separate app in the spread etc.

The plan is to treat the player as a trusted prompt session and not as an app. That means it will not appear in the app scope or the launcher, but as an overlay to the video scope or whatever starts it.

NOTE: The fixes for this bug are on hold pending the splash screen work for trusted prompt sessions that are discussed in bug 1352251

@ted.
What work for the splash screen? As far as I am aware, there shouldn't be any splash screens for UI processes launched by a prompt helper.

@Nick, we were discussing that the shell should (optionally) provide a transition/splash screen/something for trusted prompts (as requested/configured by the trusted helper when creating a trusted session) to improve the user experience while waiting for the new UI to load.

Output from a chat with tvoss today:

We foresee two parallel approaches: a media player widget and a player using trusted sessions.

1)
If your app has video playback caps + apparmor profile, you should just be able to go:

VideoPlayer { // name TBD, component to be ~extracted from the current media player app into the SDK
    source: "url://to/video"
}

That's it. It should be an item as any other in your QML scene, and have a button to put it fullscreen. Hardware decoding included.

2)
If you don't want to embed the player in your app, dispatching a URL to it should result in the video player opening as a trusted session for your app, covering it whole.

That might not necessarily be the behaviour we want for windowed mode, where we might want an actual player app, but that we'll have to determine when we get there.

I like it, I think it's a good plan. You should check with bfiller and his
team, as from my memory they started on a media player widget already.

On Thu, Feb 5, 2015 at 10:52 AM, Michał Sawicz <email address hidden>
wrote:

> Output from a chat with tvoss today:
>
> We foresee two parallel approaches: a media player widget and a player
> using trusted sessions.
>
> 1)
> If your app has video playback caps + apparmor profile, you should just be
> able to go:
>
> VideoPlayer { // name TBD, component to be ~extracted from the current
> media player app into the SDK
> source: "url://to/video"
> }
>
> That's it. It should be an item as any other in your QML scene, and have
> a button to put it fullscreen. Hardware decoding included.
>
> 2)
> If you don't want to embed the player in your app, dispatching a URL to it
> should result in the video player opening as a trusted session for your
> app, covering it whole.
>
> That might not necessarily be the behaviour we want for windowed mode,
> where we might want an actual player app, but that we'll have to
> determine when we get there.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1343353).
> https://bugs.launchpad.net/bugs/1387691
>
> Title:
> Media Player should not be visible in the app scope and launcher
>
> Status in the base for Ubuntu mobile products:
> In Progress
> Status in Ubuntu UX bugs:
> Fix Committed
> Status in mediaplayer-app package in Ubuntu:
> In Progress
> Status in unity8 package in Ubuntu:
> Invalid
> Status in url-dispatcher package in Ubuntu:
> In Progress
> Status in mediaplayer-app package in Ubuntu RTM:
> In Progress
> Status in url-dispatcher package in Ubuntu RTM:
> In Progress
>
> Bug description:
> The mediaplayer is an 'auxiliary app' in the current design approach.
> That means that its purpouse it playback media launched by other apps
> (e.g Messaging) or scopes (e.g. Videos). It should not be launched
> from the App scopes.
>
> However, the 'Update' section System Settings should still display it
> when an update to mediaplayer is available.
>
> Current behaviour
> - Mediaplayer app displayed in App Scope, Launcher and Settings
>
> Desired behaviour
> - Mediaplayer app not displayed in App Scope or Launcher
> - Mediaplayer displayed in Settings > Update
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1387691/+subscriptions
>

pushing out as no way it lands this week

Hi,
I'm testing this bug on R19 version.
About comment #10, if the idea is to treat the player as a trusted prompt session and not as an app, and hide the app icon, then if the user wants to reproduce a video and he/she does not have data or wifi connection, his/her own videos won´t be shown on the vieo scope, so there would be no way of reproducing them.
In my opinion hiding the app icon should be just something provisional until finding the solution.
Truly, I am a little lost about which would be the solution that would land on ww11. Could someone confirm me this?
Thank you.
Regards

@saviq
I agree with the 2 approaches from comment #14. However neither are really feasible for RTM without doing a sizable amount of work:

1) For the embedded video component
- my team would create the component, and move it into ui-extras to start with. We started this a while ago here:
https://code.launchpad.net/~renatofilho/mediaplayer-app/share-components/+merge/241599, but this would need to be finished
- modify Video scopes to use the component
- modify Gallery and Camera to use the component

2) Trusted session support
For this to land, there are a couple of blocking issues that need to be sorted on Unity and/or Scopes
- fullscreen window support - this is needed because users expect video playback to happen in fullscreen mode as it does today when launching mediaplayer-app via url-dispatcher.
- feedback when launching - based on ted's prototype of launching mediaplayer-app as a trusted session, there is quite some delay when launching as a trusted session. Some sort of spinner or splash screen is needed when launching it. Guessing would be better to build this into the framework somehow rather than having each client (i.e. scopes, apps) be responsible for doing it.

My suggestion is that we add these tasks to respective backlog and get them scheduled.

For the short term, I'd suggest we use "OnlyShowIn" in the desktop file of mediaplayer-app. This would hide it from the apps scope but still allow it to be launched as it is today from scopes and apps. The only downside is it would still show up in the launcher when running and could be pinned, but I'd say that is still an improvement over what we have today.

Question: what value would we set for "OnlyShowIn"?

Thoughts?

The problem with the "OnlyShowIn" approach is that it is going to create a really odd user experience. Should the app show up in the Launcher? What about the application spread? What if someone pins it on the launcher? Providing something that is both an application in some states but not others is only a route to confusing the user.

Along with that, it's really not where we want to go long term. We want to move towards more helpers and less applications for this type of functionality. It breaks the architecture that we're trying to build. I think that CI Train has taught us how long "temporary fixes" can burn us :-)

Perhaps there is a middle ground on trusted session splash screens where it could be at least a black screen so the user can tell *something* is happening.

Could someone make me a summary of the final design or abut what it's been decided?

Any news?

A new solution has been proposed by design. The shell will be responsible for overlaying a video playback screen on top of the current app or scope. The mediaplayer app will go away, and will be replaced by this functionality in the shell.

On Tue, 2015-05-26 at 16:43 +0000, Bill Filler wrote:

> A new solution has been proposed by design. The shell will be
> responsible for overlaying a video playback screen on top of the current
> app or scope. The mediaplayer app will go away, and will be replaced by
> this functionality in the shell.

I think that this bug is still valid though for cases of other apps
wanting to play video though? Especially for non-QML apps that can't use
the widgets we provide.

The URL Overlays feature in URL Dispatcher solves this problem. There's a branch for mediaplayer that implements URL Overlays there but it needs mediahub support as well. Marking it complete in URL Dispatcher.

What is finally going to happen with the error message that this app shows?

This bug was fixed in the package mediaplayer-app 0.20.5+15.04.20150701-0ubuntu1 in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay

---------------

mediaplayer-app (0.20.5+15.04.20150701-0ubuntu1) vivid; urgency=medium

  [ Bill Filler ]
  * use OnlyShowIn=Old to hide from Apps scope (LP: #1387691)

  [ Renato Araujo Oliveira Filho ]
  * Fixed slider positioning. (LP: #1470331)

mediaplayer-app (0.20.5+15.10.20150630-0ubuntu1) wily; urgency=medium

  [ Renato Araujo Oliveira Filho ]
  * Updated app icon. (LP: #1457424)

mediaplayer-app (0.20.5+15.10.20150522-0ubuntu1) wily; urgency=medium

  [ Jim Hodapp ]
  * Quit playback after fatal playback error. (LP: #1435088)

mediaplayer-app (0.20.5+15.04.20150428-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Ricardo Mendoza ]
  * Bug #1417006 Performance/Rendering fixes:  * Remove clipping on
    video loader  * Remove unused rectangles (overdraw) (LP: #1417006)

 -- CI Train Bot <email address hidden> Wed, 01 Jul 2015 21:53:38 +0000

This bug was fixed in the package mediaplayer-app - 0.20.5+15.10.20150701-0ubuntu1

---------------
mediaplayer-app (0.20.5+15.10.20150701-0ubuntu1) wily; urgency=medium

  [ Bill Filler ]
  * use OnlyShowIn=Old to hide from Apps scope (LP: #1387691)

  [ Renato Araujo Oliveira Filho ]
  * Fixed slider positioning. (LP: #1470331)

 -- CI Train Bot <email address hidden> Wed, 01 Jul 2015 21:53:38 +0000

Asked JohnLea to reset the status of this bug until fix is fully implemented.

This bug was fixed in the package mediaplayer-app 0.20.5+15.04.20160106.1-0ubuntu1 in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay

---------------

mediaplayer-app (0.20.5+15.04.20160106.1-0ubuntu1) vivid; urgency=medium

  [ Arthur Mello ]
  * Add X-Ubuntu-Touch=true to desktop file (LP: #1521773)
  * Translate app title (LP: #1521186)

mediaplayer-app (0.20.5+15.10.20150701-0ubuntu2~gcc5.1) wily; urgency=medium

  * No-change test rebuild for g++5 ABI transition

mediaplayer-app (0.20.5+15.10.20150701-0ubuntu1) wily; urgency=medium

  [ Bill Filler ]
  * use OnlyShowIn=Old to hide from Apps scope (LP: #1387691)

  [ Renato Araujo Oliveira Filho ]
  * Fixed slider positioning. (LP: #1470331)

mediaplayer-app (0.20.5+15.10.20150630-0ubuntu1) wily; urgency=medium

  [ Renato Araujo Oliveira Filho ]
  * Updated app icon. (LP: #1457424)

mediaplayer-app (0.20.5+15.10.20150522-0ubuntu1) wily; urgency=medium

  [ Jim Hodapp ]
  * Quit playback after fatal playback error. (LP: #1435088)

 -- Bill Filler <email address hidden> Wed, 06 Jan 2016 17:11:48 +0000