On 27/07/06, Jonathan Gordon <[EMAIL PROTECTED]> wrote:
On 27/07/06, [IDC]Dragon <[EMAIL PROTECTED]> wrote:
> > well, seen as im not really getting any feedback,
>
> Heh, sorry for not following this in detail. I'd be interested if and how
much this saves on code size vs. the extra tables. Anyth
On 27/07/06, [IDC]Dragon <[EMAIL PROTECTED]> wrote:
> well, seen as im not really getting any feedback,
Heh, sorry for not following this in detail. I'd be interested if and how much
this saves on code size vs. the extra tables. Anything which helps to get the
critical Archos footprint smaller
> well, seen as im not really getting any feedback,
Heh, sorry for not following this in detail. I'd be interested if and how much
this saves on code size vs. the extra tables. Anything which helps to get the
critical Archos footprint smaller is a great help.
Jörg
--
Echte DSL-Flatrate dau
well, seen as im not really getting any feedback, Ive implemented this
all for the list widget (which includes the tree and menus)
the patch is at http://jdgordon.mine.nu:8080/button_changes.patch
please someone give it a try and let me know how it goes.
The buttons for the iriver's are the same,
On 25/07/06, RaeNye <[EMAIL PROTECTED]> wrote:
Actually I thought of a more general event loop scheme.
There's a event queue (may unified with the thread queue, maybe not),
The ADC code pushes "raw" button events, e.g., BUTTON_PLAY or BUTTON_NONE;
Every plugin/menu/gui thing has a get_event() -
.
R.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Gordon
Sent: Monday, July 24, 2006 2:40 PM
To: Rockbox development
Subject: Re: half-idea for #ifdef and key deifnition hell...
Hey all,
OK, well I've had a bit more of a play with implemen
Hey all,
OK, well I've had a bit more of a play with implementing this idea and
I want to show you what it looks like now before I have it finished
and you all decide its not workable.
ok, so here is what goes in the existing button.h file (although that
file will get rediculously long so maybe s
well, now the freeze has thawed (hoho someone shoot me :p ) can we get
some discussion on this happening?
I reckon the button #define hell should be one of the first things tackled.?
On 29/05/06, Fredrik Öhrn <[EMAIL PROTECTED]> wrote:
Jonathan Gordon wrote:
> ??
> first the switch/if..ifelse i
Jonathan Gordon wrote:
> ??
> first the switch/if..ifelse is just a matter of style.. and the switch
> uses 1 less variable.. but it really makes no diff...
> which for loop are u talking about?
Sorry, I meant while-loop, the one inside read_button() that loops over the
items array.
> as for chec
??
first the switch/if..ifelse is just a matter of style.. and the switch
uses 1 less variable.. but it really makes no diff...
which for loop are u talking about?
as for checking for long/short/dbl clicks in the actual button
driver.. how does it know to wait for a double click instead of diong
2
Jonathan Gordon wrote:
> hey all,
> well iv had another play with this and i tinhk it actually works :O
> attached is a demo plugin that just tests the loop.. hopefully its all
> simple enough to understand without thinking too much..
> the idea of line 12-35 is that there would be a standard list
hey all,
well iv had another play with this and i tinhk it actually works :O
attached is a demo plugin that just tests the loop.. hopefully its all
simple enough to understand without thinking too much..
the idea of line 12-35 is that there would be a standard list of
buttons that would be global
On 24/03/06, Brandon Low <[EMAIL PROTECTED]> wrote:
> Yer a smart one.
:)
>
> I hoep you keep noodling on this while we're all busy doing 3.0 :)
ye, thats why im playing with it.. figured i may aswell do something
while everyone else is getting ready for 3.0
>
> On Fri, 03/24/06 at 12:08:47 +1100,
Yer a smart one.
I hoep you keep noodling on this while we're all busy doing 3.0 :)
On Fri, 03/24/06 at 12:08:47 +1100, Jonathan Gordon wrote:
> maybe we do a simple last button cache thing?
> i.e if button == last_button then start the loop at the last i..
> of, even just cache the last return_c
maybe we do a simple last button cache thing?
i.e if button == last_button then start the loop at the last i..
of, even just cache the last return_code and return that imediatly.. i
think that would work?
On 24/03/06, Brandon Low <[EMAIL PROTECTED]> wrote:
> Scroll events happen frequently enough
Scroll events happen frequently enough to be worth concern, as do
button_repeat events...
Darn those remote controls.
Brandon
On Thu, 03/23/06 at 14:45:07 +0100, Bj?rn Stenberg wrote:
> Brandon Low wrote:
> > I think that button processing can't be going through lists like that,
> > too slow.
>
Brandon Low wrote:
> I think that button processing can't be going through lists like that,
> too slow.
I'm not so sure. Buttons are pressed rather rarely (from a system/cpu point of
view) and the lag cause by looping through a few dozen entries will probably
not be measurable, let alone noticea
I think that button processing can't be going through lists like that,
too slow.
Something that came up at devcon was the concept of more different
button code modifiers that the button driver can convert to:
BUTTON_NAME | BUTTON_SHORT
BUTTON_NAME | BUTTON_LONG
BUTTON_NAME | BUTTON_REPEAT
BUTTON_
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 Bu
On Thu, 03/23/06 at 10:06:57 +1100, Jonathan Gordon wrote:
> On 23/03/06, Brandon Low <[EMAIL PROTECTED]> 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
On 23/03/06, Daniel Stenberg <[EMAIL PROTECTED]> wrote:
> On Thu, 23 Mar 2006, Jonathan Gordon wrote:
>
> > im not entirely sure :p i was hopeing this msg would get more responses...
>
> When we discussed this at devcon, we decided there was no way we could squeze
> such a huge overhaul into 3.0. T
On Thu, 23 Mar 2006, Jonathan Gordon wrote:
im not entirely sure :p i was hopeing this msg would get more responses...
When we discussed this at devcon, we decided there was no way we could squeze
such a huge overhaul into 3.0. That might also be a reason why not so many
replies: we work har
On 23/03/06, Brandon Low <[EMAIL PROTECTED]> 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 logi
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
ok, ive done more playing with buttons..
http://users.monash.edu.au/~jdgor1/rb/button_list.txt is a list of
every unique button definition in the source (excluding the plugins)
(its possible i missed a few but that shouldnt matter)
http://users.monash.edu.au/~jdgor1/rb/suggested_button_list.txt is
25 matches
Mail list logo
