Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by fml2 - 2009-01-28
Last edited by jdgordon - 2009-02-01

FS#9845 - Status bar is not drawn in the WPS

Sansa e280 with FM tuner, r19871

My settings are:
- status bar: no
- the WPS used is very simple, it does contain the %we tag to switch the status bar on

But the status bar is not shown in the WPS

Here is the WPS I use:
%we

%ac%s%?ia<%ia|%d2>
%ac%s%?it<%it|%fn>

%al%pc%ac%pp/%pe%ar-%pr
%pb

%ac%s%?It<%It|%Fn>

Closed by  jdgordon
2009-02-01 11:40
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

fixed in r19894.

jdgordon commented on 2009-01-29 00:31

the statusbar has never been displayed in the WPS if the setting was set to no…

fml2 commented on 2009-01-29 19:21

Are you sure? I can’t remember. But I admit that the tag description is a little bit unspecific. It says “enable” and “disable”. I’d interpret this as “switch on” or “switch off”. I.e. with “%we” I can be sure that the status bar is displayed – regardless of the setting. And the same for %wd: with it, I can be sure that the status bar is not displayed even if it’s set to ON in the settings.

rasher commented on 2009-01-29 19:28

I’m pretty sure the %we / %wd tag behaves (or should behave) as Alexander says, an override to the global setting - that’s the entire reason they exist. This is definitely a bug.

jdgordon commented on 2009-01-30 00:26

I’ll check the svn log later, but no, the statusbar checks global_settings before drawing (and im sure it has always done this)

rasher commented on 2009-01-30 01:08

If it does that, what would the reason for the %we and %wd tag be? I remember when they were added, and the entire point was to allow the WPS to override the global setting.

See  FS#2677  - this behaviour has quite simply been broken, and that’s a bug.

jdgordon commented on 2009-01-30 01:17

arg, I’m confused… the reason I thought this is because there is a hack in the radio code to temporarily enable the statusbar so it can draw.. but just checked and the wps bypasses the global_settings.statusbar check… this is indeed a bug.. one I’m not entirely sure how to fix. :(

kugel. commented on 2009-01-31 18:38

AFAIK %we and %wd are both to overrde global settings (so I’m with rasher and fml2).
To use settings, one should just omit both %we and %wd.

fml2 commented on 2009-01-31 23:44

I think the problem is in viewport.c:95. The status bar is only displayed if the global setting is set to YES. IMO we should make the function “viewportmanager_set_statusbar” only respect the passed parameter and not add its own “intelligence” by adding this condition. The callers of the function have more specific contexts and hence should be responsible for passing an appropriate value. The WPS code does it (gwps-common.c:85-86), but the code in viewport.c makes it wrong again. The radio screen could always use “true.” And the menu code would use the value from the global settings.

I don’t know the code and status bar concepts very well but I think I’m on the right path.

jdgordon commented on 2009-01-31 23:47

yes, I’ve got a patch ready which fixes this but makes viewportmanager_set_statusbar more complicated… it will get commited today after a bit of commenting and cleaning up

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing