FS#5652 - Keep backlight on in JPEG plugin

Attached to Project: Rockbox
Opened by Matthias Mohr (aka Massa) (mmohr) - Wednesday, 12 July 2006, 11:57 GMT
Last edited by Jonas Häggqvist (rasher) - Wednesday, 12 July 2006, 18:27 GMT
Task Type Patches
Category Plugins
Status Closed
Assigned To Matthias Mohr (aka Massa) (mmohr)
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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.
This task depends upon

Closed by  Peter D'Hoye (petur)
Wednesday, 12 July 2006, 23:15 GMT
Reason for closing:  Accepted
Comment by Matthias Mohr (aka Massa) (mmohr) - Wednesday, 12 July 2006, 16:38 GMT
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,
why not the JPEG plugin?
(brickmania, clock, credits, demystify, fire, grayscale, oscilloscope,
plasma, spacerocks, startfield, tetrox, video, xobox)
Comment by Nicolas Pennequin (nicolas_p) - Wednesday, 12 July 2006, 16:46 GMT
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...
Comment by Matthias Mohr (aka Massa) (mmohr) - Wednesday, 12 July 2006, 17:00 GMT
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?
Comment by Paul Louden (darkkone) - Wednesday, 12 July 2006, 18:20 GMT
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.
Comment by Peter D'Hoye (petur) - Wednesday, 12 July 2006, 21:38 GMT
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.
Comment by Paul Louden (darkkone) - Wednesday, 12 July 2006, 21:39 GMT
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.
Comment by Peter D'Hoye (petur) - Wednesday, 12 July 2006, 23:04 GMT
nevermind that 'fishy' remark, it was caused by me mixing patched and cvs builds