From: nobby <nobbynobbs_at_gmail.com>
Date: Thu, 07 Jul 2005 12:22:24 +0100

On Thu, 7 Jul 2005 11:40:01 -0400 (EDT), Ray Lambert
<listlizard_at_interthingy.net> wrote:

> Linus Nielsen Feltzing wrote:
>> Ray Lambert wrote:
>>> Does anyone control what goes in then? Or do you just back things
>>> out when someone submits something that isn't popular?
>>
>> If someone does that, we seek him up and kill him. :-)
>
> Sounds very effective... ;-)
>
>
>>> For my own part (regarding my A-B Repeat patch) I've tried to be
>>> careful to cross all the t's and dot all the i's but I discovered
>>> after posting my latest update that I accidentally broke the
>>> simulator. I usually check that before releasing but forgot to this
>>> time. I will post a new update soon that fixes this.
>>
>> While you do that, also make sure that your LANG entries are last in the
>> file. Also make sure that you bump the setting block version number,
>> since the repeat setting must be 3 bits instead of 2 (thanks to the new
>> "shuffle" repeat mode.
>
> Okay. I'll have to take a look at those shuffle changes.
>
>
>>> As for the display, I've implemented a graphical marker to show the A
>>> & B marks for 'HAVE_LCD_BITMAP' devices.
>>
>> I'm not sure how they should look like, but they look like they are one
>> pixel too high in my (default) WPS. I had to change the drawing code due
>> to the LCD API change, maybe I screwed up somehow...
>
> Is that change more recent than 6/14? If so, I haven't seen it yet; I'll
> take a look.
>
> The markers are usually drawn as an arrow head with the A marker pointing
> right and B pointing left (if the markers are too close together, only a
> vertical bar is drawn). They are drawn on top of the progress bar in XOR
> mode so they still make some sense regardless of the song/scroll bar
> position. There are no hard-coded positions and only the height is
> hard-coded. The routine that does the actual drawing is in abrepeat.c
> (where all functional ABR code is). It is called from wps-display.c on
> the line following the scrollbar() call. The hard-coded height value
> appears in this call and is the same as used in the scrollbar() call.
> All
> other values are the ones calculated locally as the screen is being
> laid-out and drawn.
>

Isnt the scrollbar taller in iriver than recorder?

> In any case, I'll take a look at it when I update the patch.
>
>
>>> If all else fails, I've wrapped all of my code in '#ifdef
>>> AB_REPEAT_ENABLE' (defined in abrepeat.h) so the feature can just be
>>> disabled on devices that aren't yet supported (or which cannot be
>>> supported).
>>
>> No, you used #if AB_REPEAT_ENABLE. I'd prefer #ifdef, and (temporarily)
>> have it in the config-xxx.h files.
>
> Oops, yes, you're correct. I sometimes prefer to use #if instead. It
> makes no difference to me though so I'll change them when I update.
>
>
> I was thinking last night about the inability to add a status icon on the
> non-bitmap display devices and an interesting idea occurred me. I
> designed my A-B Repeat to work exactly like "Repeat One" mode if no
> markers are set. Considering this, perhaps it would be better to simply
> add the A-B functionality to Repeat One mode and NOT add a new mode for
> ABR? Repeat One would only behave differently if a marker is set. This
> would remove the need for certain requirements, such as the status icon,
> config file changes, setting block changes, etc. What do you think of
> this?
>
> ~ray
>
>
> _______________________________________________
> http://cool.haxx.se/mailman/listinfo/rockbox

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox

Received on 2005-07-07