| Summary: | Screen no longer locks after inactivity while Haruna is running | ||
|---|---|---|---|
| Product: | [Applications] Haruna | Reporter: | Aaron Miller <kdeaaron> |
| Component: | generic | Assignee: | george fb <georgefb899> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/multimedia/haruna/commit/e558fc68511913587745fa797aab36be1f5e4cee | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
|
Description
Aaron Miller
2023-02-13 01:21:35 UTC
This was actually a bug in Haruna Media Player -- whenever it was running, the screen wouldn't lock. I don't know if the external monitor status has anything to do with this. Generally it's considered intentional for video players to inhibit screen locking while playing video. If they didn't, then you could have the screen lock on you while you were watching the video! However if the app is inhibiting screen lock while simply running--rather than while playing a video--that would be an app bug. Can you do some tests to determine this? Hi Nate, I was able to inhibit locking just by starting Haruna (no media playing or even paused). Git commit e558fc68511913587745fa797aab36be1f5e4cee by George Florea Bănuș. Committed on 10/04/2023 at 03:56. Pushed by georgefb into branch 'master'. mpvitem: don't emit `..Changed` signals when setting certain properties the signal is emitted in the `eventHandler` method M +4 -8 src/mpv/mpvitem.cpp https://invent.kde.org/multimedia/haruna/commit/e558fc68511913587745fa797aab36be1f5e4cee |