I would rather have media controls in the greeter.
I don't like yet another option that does something rather weird :/

Seems sensible. +1

As it's an RFC, it's a shame we have so much duplicated code for media player management; but I don't think there's any existing simple way round that. Any thoughts on how we collectively can fix that?

Like Marco I would prefer proper media controls. The feature like that doesn't make sense IMHO.

The feature like that doesn't make sense IMHO.

Why?

Media controls doesn't help with this usecase. You come back, you press resume, your movie resumes...whilst your screen is still locked.
And if you unlock first..then you don't have the controls visible to press resume.

Surely the ideal world is one where the movie player realises the screen is locked and makes the decision to pause by itself? Media controls might still be a better option for audio players, but I wonder whether volume controls are better than that?

In D3674#68838, @davidedmundson wrote:

The feature like that doesn't make sense IMHO.

Why?

Media controls doesn't help with this usecase. You come back, you press resume, your movie resumes...whilst your screen is still locked.

Video should inhibit screen locker.

But for the sake of argument let's assume the usecase is valid. Yes for movies I agree, but for audio I disagree. I would find it highly annoying if audio stops on screen lock. And I would find it even more annoying to have to change the settings depending on the kind of media I'm interacting with.

the mpris interface supports video and audio - I don't think that one option can handle both.

So, about proper media controls, would re-using the mpris data engine in Plasma from QML be an option or should it rather be some implementation in ksldapp given you wanted to disable dbus access for the locker?

reusing the existing engine is fine. For disabling dbus access I rather hope that we can use apparmor at some future point and lock with that.

But for the sake of argument let's assume the usecase is valid.

No assumption is needed, it *is* valid. Assuming you have lock on suspend, which is the default:

Case 1:
You run out of power.

Case 2:
You close the lid

Having the movie contiue before you've logged back in is a state I've been in.

Separate video/audio settings is a good comment though.

Kai, can you expand on your use cases, especially as it's an RFC, you need to have a much longer description than a title.
I'm having to guess what problem you were solving, which probably means everyone else is too.

Having the movie contiue before you've logged back in is a state I've been in.

Arguable that could also be handled by the media players by doing a temp inhibit to pause the movie. But yes that makes sense, but maybe more in powermanagement than in lock screen. I think after a suspend movie should always be paused, whether the screen is locked or not.

use apparmor at some future point

and from what I understand DBus access can be restricted on a per-interface/service basis with that? Dunno if it can do wildcards, though.

Kai, can you expand on your use cases

At Randa I was listening to music, then when I locked my screen to get some more coffee, I always forgot to pause my music and since Plasma encourages you to be lazy usually, that's when I really wanted that feature and even built a hack into media controller applet for the rest of the week.

I think after a suspend movie should always be paused

I like that, what about me adding a checkbox to PowerDevil to have it pause music on suspend? That would fix [1] (I know we forward media keys but I still liked that scene in that video).

[1] https://www.youtube.com/watch?v=cQoQE_HDG8g&t=32m6s