|
Rockbox mail archiveSubject: Plugin button actionsPlugin 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 template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |