- Status Closed
- Percent Complete
- Task Type Patches
- Category Plugins
-
Assigned To
mmohr - Operating System All players
- Severity Low
- Priority Very Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#5652 - Keep backlight on in JPEG plugin
BUG: When you’re viewing JPEG pictures with the JPEG plugin,
it’s really annoying that the backlight switches off after
the configured time.
I produced an patch which fixes this.
It keeps the backlight on when inside the JPEG plugin
and resets the timeout settings when leaving the plugin.
jpeg_backlight_20060712.patch
(1.2 KiB)
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Why has this be changed to be a “Feature Request”?
The whole title is now wrong and does people lead to the wrong direction
(it’s not about a new feature for “backlight switches off when in JPEG plugin”,
it’s about a BUG that the backlight switches off).
Is there anybody out there who treats the current behaviour
of switching off the backlight when watching a JPEG slideshow
as normal and not as bug?
I doubt it!
BTW, a lot of other plugins permanently switch on the backlight,
(brickmania, clock, credits, demystify, fire, grayscale, oscilloscope,
plasma, spacerocks, startfield, tetrox, video, xobox)
Shouldn’t this be listed as a patch ?
The title “Disable backlight timeout in JPEG viewer” would seem quite descriptive and appropriate to me.
IMHO, the backlight switching off in the JPEG is not a bug, just a normal behaviour which becomes annoying in certain specific situations. Maybe making it a setting in the JPEG viewer options would be a good solution…
Nicolas, for me it was (and still is) totally clear that this is a bug.
So I added it as BUG to the tracker and provided a patch to fix the bug.
For me the whole thing does not make sense as “feature request”
Again: other plugins work the same way, so why not the JPEG plugin?
It’s simple:
Requesting a change of existing behaviour is a feature request. Whether the behaviour is good or bad, if it’s things working how they’re written to work, then changing it is a feature request.
If things are written one way, and work another way, it’s a bug.
It is not a bug just because you don’t *like* the way it works. This sorta needs to be maintained, otherwise “The UI is bad” becomes a bug report, because the Play button goes to WPS while in the filetree but not in the Menu, and so on.
Sorry to state the opposite, but for me a screensaver firing off during a slideshow is maybe not a bug but at least a big inconvenience for the user, and thus should be taken care of.
Massa, tried your patch but something is fishy, it did some weird things with backlight (like switching it off when exiting) so I’ll need to look deeper into how this is implemented.
People seem to miss my point. I’m not saying the patch is a bad idea in ANY way. I like it. I’m for inclusion. My ONLY statement was that it isn’t a bug the way it is right now, and therefor complaints about it would be “feature requests” not “bugs.”
That is ALL I said.
nevermind that ‘fishy’ remark, it was caused by me mixing patched and cvs builds