Bug 1031

Created attachment 672 [details]
Blocking screensaver using fake events (v3.5.13)

For some time I struggled with solution to blocking screensaver in Kaffeine. So I thought to bring into KMPlayer the same solution as is used in Kaffeine. Proposed patch attached. You need to add libxtst-dev to build-deps. Please, test it before I'll push it into GIT.

Created attachment 673 [details]
Blocking screensaver using fake events (R14)

I tested the proposed R14 patch.

I temporarily set my screen saver timeout to 1 minute.

With kmplayer in normal view mode, the screen saver did not activate while playing a 3 minute video.

When the 3 minute video completed, 1 minute later the screen saver activated.

So that part of the bug report is resolved. Nice work!

Quirk:

When in full view mode and the video completed, kmplayer returns to normal view mode. The screen saver activated in only 20 seconds rather than 1 minute. With another test the screen saver activated after 54 seconds rather than 1 minute. This is better better than not activating at all, but odd to not activate after 1 minute. Does this have anything to do with sending fake mouse events? I don't know.

Remaining to be resolved:

Pausing a video, in either full or normal view mode, does not re-enable the screen saver.

(Odpověď na komentář #3)
> Quirk:
> 
> When in full view mode and the video completed, kmplayer returns to normal view
> mode. The screen saver activated in only 20 seconds rather than 1 minute. With
> another test the screen saver activated after 54 seconds rather than 1 minute.
> This is better better than not activating at all, but odd to not activate after
> 1 minute. Does this have anything to do with sending fake mouse events? I don't
> know.

Interesting. I tried it in v3.5.13.1 in both Debian Squeeze, so on Ubuntu Precise. In both saver is activated just 1 minute after the end of film.

> 
> Remaining to be resolved:
> 
> Pausing a video, in either full or normal view mode, does not re-enable the
> screen saver.

If I understood correctly in the code, so the  kmplayer does not keep state of playing => no function that can be reasonably determined that the playback is paused. It would be necessary first of all in the all backends to implement such a feature.

Created attachment 676 [details]
Blocking screensaver using fake events (v3.5.13)

Fixed some FTBFS

Created attachment 677 [details]
Blocking screensaver using fake events (R14)

Being curious, I just tried the same thing with kaffeine. With my screen saver timeout set to 1 minute, pausing a video in kaffeine activated the screen saver after 1 minute. Perhaps then the same code snippets could be grabbed from kaffeine?

(Odpověď na komentář #7)
> Being curious, I just tried the same thing with kaffeine. With my screen saver
> timeout set to 1 minute, pausing a video in kaffeine activated the screen saver
> after 1 minute. Perhaps then the same code snippets could be grabbed from
> kaffeine?

Kaffeine provides isPaused method on backend object. Conditions ensuring the locking screen saver contain: !m_mediaPart-> isPaused().

KMPlayer does not provide common isPaused function. Each backend detect the state of playing internally. It would therefore be possible to extend the backend object interface to provide such a method.

Is the lack of an isPause function a bug or an enhancement request? How much work is involved to copy that code from kaffeine to kmplayer? There are other bugs needing more attention for R14 and 3.5.13.1 than this remaining issue.

If this is more of an enhancement than a bug then we should push the current patches and open a new bug report/enhancement request. If the lack of an isPause function is a bug then we can still push the current patches (the GIT patch works for me and you) and leave this bug report open to resolve that issue.

I think this is enhancement request. As backends Kaffeine and KMPlayer differs, probably can not be simply copy the code. However, the necessary code would probably be in the methods "pause". Give me some time and try to implement it.(Odpověď na komentář #9)
> Is the lack of an isPause function a bug or an enhancement request? How much
> work is involved to copy that code from kaffeine to kmplayer? There are other
> bugs needing more attention for R14 and 3.5.13.1 than this remaining issue.
> 
> If this is more of an enhancement than a bug then we should push the current
> patches and open a new bug report/enhancement request. If the lack of an
> isPause function is a bug then we can still push the current patches (the GIT
> patch works for me and you) and leave this bug report open to resolve that
> issue.

I think this is enhancement request. As backends Kaffeine and KMPlayer differs, probably can not be simply copy the code. However, the necessary code would probably be in the methods "pause". Give me some time and try to implement it.

If it proved to be difficult, I will inform and set aside for later.

Created attachment 678 [details]
Blocking screensaver using fake events (v3.5.13)

The solution then was even easier than I expected:
Added isPaused method to PartBase

Created attachment 679 [details]
Blocking screensaver using fake events (R14)

Don't spend much time on that. Obviously kmplayer never was designed originally with those features.

Let me open an enhancement request and you can push your patches to close this report. Then you can spend time productively with more important bugs. :-)

Clever man! :-)

Looks like I need to test the latest patch. :-)

(Odpověď na komentář #14)
> Clever man! :-)
> 
> Looks like I need to test the latest patch. :-)

Yes - isPaused is solved!
Please, test yourself and then I'll pushing it into Git.

The new isPause function works in normal view --- good job!

The new isPause function does not work in full view mode. :-(

(Odpověď na komentář #16)
> The new isPause function works in normal view --- good job!
> 
> The new isPause function does not work in full view mode. :-(

I have a theory: Pause by Space is solved internally by Xine - without the knowledge of KMPlayer. Therefore Space works, although in KMPlayer such key is not set. And therefore about this stop KMPlayer are not aware => isPaused returns false.

Try to set in KMplayer Space as key to stop.

I set the Space key to Pause in my proposed patch in bug report 1032.

(Odpověď na komentář #18)
> I set the Space key to Pause in my proposed patch in bug report 1032.

I found it! In src/xineplayer.cpp, lines from 836. The keys are regardless of the configuration of KMPlayer. Xine is controlled without use PartBase => without the rest of the KMPlayer. It will probably be harder to fix.

Darrell, we will now attempt to correct bugs in fullscreen mode? I would suggest to push to GIT our current patches. And for bugs in fullscreen mode start a new bug message. And leave it for another time. What do you think?

Sounds good to me. Push what we have and create a new bug report against full view mode problems.

Before you push the patches in this bug report, please test the patch in bug report 1032. They all go together.

Same complaint in 1032: failures in full view mode but otherwise the new shortcuts seem to be working. I'd like at least one other person besides me to test the 1032 patch before pushing to GIT.

Slavek,

How about we push the screen saver patch and close this bug report?

The keyboard shortcuts patch (bug report 1032) needs a bit more work. We need to fix the focus and Alt-Tab issues.

We can open a new bug report to address full view mode quirks and bugs.

Fixed in GIT hash 8fe6f082.