BUTTON CHANGES - REPORT PROBLEMS HERE

[slash14]

Might sound as a stupid question but isn't it a declaration (at the very beginning of the file) ?

Code: [Select]

enum {
    METRONOME_PLAY_TAP = LAST_PLUGINLIB_ACTION+1,
#if CONFIG_KEYPAD == ONDIO_PAD
    METRONOME_PAUSE,
#endif
#if (CONFIG_KEYPAD == IRIVER_H100_PAD) || (CONFIG_KEYPAD == IRIVER_H300_PAD)
    METRONOME_SYNC
#endif
};Without proper declaration, I think that compilation would not succeed, is it ?

[Mmmm]

For an #ifdef to trigger, it must have been #define 'd first.
With the new button code for plugins you can't do this as it is using a button that is specific to one set of players only (ie the record button doesn't have a general keymap).
You could give it a general keymap and call it BUTTON_RECORD or something

or you could use
#if (CONFIG_KEYPAD == IRIVER_H100_PAD) || (CONFIG_KEYPAD == IRIVER_H300_PAD)
instead of the #ifdef but that would make adding this functionality to other players, if you wanted to, a real pain.

or you could have something like
#if (CONFIG_KEYPAD == IRIVER_H100_PAD) || (CONFIG_KEYPAD == IRIVER_H300_PAD)
#define MET_SYNC
#endif
at the beginning and then have lots of #ifdef MET_SYNC instead.

Not being too familiar with (and being too lazy to look at) the Plugin button system I think I'll leave it to JDGordon who I'm sure will really enjoy deciding which is best

[JdGordon]

? I thought #ifdef worked for all names in the file, so enum and function names and such...
ok, ill fix that then

[Genre9mp3]

A minor problem I noticed yesterday. In the menu of VU Meter plugin, Up acts like Down and vice versa. Everything else seems OK. Tested on H300.

[JdGordon]

just checked the code for that menu and its using a custom menu, which means that the button changes of 6 months ago had no effect on them. BUT it does look like up/down are switched which is odd...

[nls]

I have found a minor annoyance in the WPS context menu. If I press right on the reshuffle playlist item in the menu it just goes back to the WPS and does not reshuffle, works fine if I press NAVI though...

[JdGordon]

nls: ok thats wierd.. I seem to be getting the opposite here (h300). righ works, navi doesnt..

actually.. no, i tihnk both work, but for some reason its more instant with right!

[nls]

Yes you're right both works for me now but it takes a good 10 seconds for the wps nex song and the playlist viewer to update even with a playlist of about 15 tracks... guess it's not a button problem then!  

[roolku]

Following on from our discussion on IRC regarding button presses being eaten after exiting certain plugins I have done more experiments.

A plugin only containing:

Code: [Select]

while (rb->button_get(false) != BUTTON_OFF);is okay

Code: [Select]

   while (rb->button_get(false) != (BUTTON_OFF | BUTTON_REL));is not okay

Code: [Select]

while (rb->button_get(false) != BUTTON_OFF);
rb->splash(HZ/3, true, "Bye now!");is not okay for a short press

Code: [Select]

while (rb->button_get(false) != BUTTON_OFF);
rb->splash(HZ/3, true, "Bye now!");is okay if I hold the button long enough for the splash to disappear

So I am guessing that there needs to be a button code in the queue (i.e. the button release) when exiting the plugin that is then eaten by the action code. If there isn't a "victim" left, the action code will eat the next intentional press available.

I tried to 'repair' calculator.rock by removing the splash screen at the end and it 'fixed' it. However this is not the correct way of solving it, it needs to be fixed outside the plugin.

EDIT:

I found a call to button_clear_queue(); in plugin_load(); immediately after the plugin returns. Removing it fixed the problem for the vast majority of plugins. Some (including the calculator) still have the problem though. Also this call was probably there for a reason, so I don't know what side-effect its removal will have on other targets.

[JdGordon]

fix committed

[tspoon]

 I know I posted this exact same problem here earlier - and I'm sure it was resolved too, but it seems to be back, or still present, in todays (r15102m-071013) build.

 Platform : Archos Player
 Problem : + and - keys transposed when incrementing/decrementing settings, or scrolling through lists of setting choices - at the bottom level. There is no problem in the top levels, on the volume adjust key sequence, or in file browser, or virtual keyboard.
 
 I don't use the player much, so I don't know if this problem has only just popped up, but I seem to recall (90% sure) it was fixed last time.

[ONE_HUMAN]

fix committed

Too bad.  Preferred the way it was.  Would be nice if we could map the buttons ourselves, and I don't mean with a patch.

[AlexP]

This is nothing to do with the change in Sansa keymap.  It was 7 months ago and regarded to an internal change in how Rockbox handled buttons.

Will you please read threads before replying and stop spamming unrelated threads with your dislike of the button change.