Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Plugin button actions

Plugin button actions

From: Marianne Arnold <m.arnold_at_infocity.de>
Date: Sat, 06 Oct 2007 00:08:34 +0200

Hi list,

last (ok. one more or less) week I almost fell over plugin button actions while preparing the C200
plugin patch which made me want to discuss their worth, especially in the current implementation,
here. In IRC I could already see that it is a hot topic that's why I am also a bit scared of it...

Here is what I came across: trying the new keymapping in the clock plugin I wondered why changing
the "skin" wouldn't work correctly, at first glance everything was properly defined for the
ACTION_SKIN_NEXT and it took my a few tries, making the observation that pressing "Down" would also
not do what I had expected first, looking into four (almost five) places in two files - to finally
find out that the plugin uses two action contexts one maps a certain action to BUTTON_UP the other
leaves it blank but is used first in the pluin. While a part of the problem lies also in how "clock"
uses these action contexts, it revealed the following problems (in my opinion):

1) Things get confusing and complicated because the button definitions and handling are scattered
across the keymaps file with a few contexts and the definition of contexts, actions and "action
handling" in the plugin file. It looks easier at first glance because people assume that it'll work
on every target, but if it does not it's very hard to find the reason and find a proper fix.

2) It introduces unexpected or at least not obvious connections between plugins; e.g. in the "clock"
case I thought that a solution could also be a change in the keymap file but then I thought "What
would that change in another plugin - and even - what plugins could be affected at all?". Even if
one kept track of all the plugins that use actions (or if all would do) then there are also
different contexts.

A "nice" example of the above mentioned problems causing just a different mess (IMO even worse than
before because it becomes hard to understand) is the bubbles plugin. Being the first plugin that was
turned into an "actions" plugin it got one exception for the Ondio keymap very soon and recently
someone added an own keymap for the E200 pad in the plugin, probably because of being afraid of
changing something somewhere else too.

3) Especially for the games though: there is a great variety of control schemes in the games which
possibly need a lot of different solutions depending on the "physical" placement of the buttons.

Conclusion: I would like to see a much more simple plugin actions system that only provides the pure
possible button presses (like "short left" <> "long left") or possible button combos so that the
plugin writer doesn't have to worry about prerequisite definitions, button releases or repeats - but
return to (then "action") definitions for each keypad per plugin, at least for the games. Surely it
will make the code in some plugins longer again but it will gain indepency and to me such a block of
defines is more readable than having to look things up in a different file. Such a "list" of pure
possible button presses could also help avoiding the use of impossible button combos for example on
the Iaudios. -- Maybe some of the applications could still use the system like it is now but it has
to be thought through more thoroughly and one plugin should never use more than one context in one
"screen".

I think it needs discussing (and I really hope a gave details and arguments for a good constructive
discussion) and have to say that unfortunately: it would be better to decide in the end how to
proceed because the mixture that's there now isn't helpful either... Best regards,

Marianne.
Received on 2007-10-06


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa