From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Thu, 23 Mar 2006 14:26:51 +1100

ok, well.. iv been playing with this idea anyway..

hmm.. looks like i put it in the wrong plugin :p this 1 doesnt use
_pre at all... anyway, here is the code iv got...
**********************
struct {
    int button_code;
    int ret_code;
    bool needs_pre;
} ButtonItem;
int read_button(struct ButtonItem *items, int button_count, int timeout)
{
    static int last_button = BUTTON_NONE;
    int button = rb->button_get_w_tmo(timeout);
    int i;
    int ret;
    if (button == BUTTON_NONE || button == SYS_USB_CONNECTED)
    {
        last_button = button;
        return button;
    }
    ret = BUTTON_NONE; /* in case the button is not in the list */
    for (i=0;i<button_count;i++)
    {
        if (items[i].button_code == button)
        {
            if (items[i].needs_pre)
            {
                if ((items[i-1].button_code == last_button) ||
(items[i-1].button_code == BUTTON_NONE))
                { ret = items[i].ret_code; break; }
            }

            else if (!items[i].needs_pre)
            { ret = items[i].ret_code; break; }
        }
    }
    last_button = button;
    return ret;
}
*****************************
now if some targets use a _pre for a button and some dont, ud define
the _pre to BUTTON_NONE on the targets its not used for, so it goes
through the list and will return the correct code regardless on
wheather or not _pre is used on a target (while still "sayuing" that
the button needs a _pre on at least on target).

wtahca think?

On 23/03/06, Brandon Low <lostlogic_at_lostlogicx.com> wrote:
> On Thu, 03/23/06 at 10:06:57 +1100, Jonathan Gordon wrote:
> > On 23/03/06, Brandon Low <lostlogic_at_lostlogicx.com> wrote:
> > > Great work! You just took some work off of Christi's plate toward
> > > cleaning up button definition hell. This is basically very closely
> > > along the lines of what we were talking about at devcon for button
> > > functions, and by moving the pre logic up to a higher level, we can
> > > reduce code size and improve clarity in the button switch loops.
> > >
> > > Some questions to ponder:
> > >
> > > What is our next step from here?
> > im not entirely sure :p i was hopeing this msg would get more responses...
> > im gonna implement the function today in 1 of my plugins that uses
> > _pre on some targets and see how it goes..
>
> I assume that this function will not have to exist within the event
> loop, so that it can be pulled back to a higher level to avoid code
> duplication?
>
> And also what Daniel said about working on other things that are 3.0
> material currently (playback.c here I come).
>
> > > Are there some button definitions which are optional or nonsensical on
> > > some targets which should be made optional?
> > > Where can we implement the _PRE logic so that it doesn't have to be
> > > duplicated all over the place, and so that (on ipod) scroll touched
> > > events don't interfere with it's proper operation?
> > im only worried about the scroll wheel events.. i dont have an ipod so
> > it might be hard to test it out... but we'll see
>
> Scroll events may initially be handled just like other button events,
> I'm interested in creating (with Mikachu's help) an absolute positioning
> system for ipod 5g targets, but that doesn't _necessarily_ have to fit
> into the normal operation of buttons. Would be nice if it did though.
>
> Brandon
> > >
> > > Thanks much for looking into this,
> > >
> > > Brandon
> > >
>
Received on 2006-03-23