Rockbox

gui_synclist uses a get_name callback to return the text for each item or
line. There are also callbacks for icons and color. It seems to me it
would make sense to also use a callback for the voice: speaking out the
items.

Advantages:

-The text and voice callbacks can be unified or at least made to follow a
similar pattern, so they get their info in the same way. Should make it
easier to maintain things and to keep the spoken info in sync with the
text.

-No need to come up with an ad hoc way to handle speech in each
context. This is currently reinvented in each context in slightly
different ways: remembering the last spoken item and waiting until we
change to another one, or setting a flag based on the list actions and
whenn the list is updated... AFAICT, the logic seems to be pretty similar
for all the contexts I've checked out and it makes sense to generalize
that functionality.

-The file browser in tree.c has this elaborate "hover delay" concept to
avoid overloading the system with disk access and talk requests when the
user moves rapidly through a directory. This functionality would be
useful in other contexts (like the playlist viewer and bookmark screen),
and I think it can help slightly even in contexts without .talk clips. By
moving this hover functionality in the list itself, I can share the
code. I have also improved it a bit in the process, and simplified
tree.c.

I've converted several lists to use this callback method and it appears
to be a good fit in all cases: dirbrowse() in tree.c, id3 viewer, playlist
catalog, playlist viewer, bookmark screen, running_time screen, radio
presets list, and my playing-time patch. Those will be posted in
separate patches of course.

It works by registering a callback function, which will be called with
the same data argument as the get_name callback. Generally, one registers
the voice callback only if talk_menus_enabled(), although in special
cases one can test the appropriate settings inside the callback
itself. The callback causes the current item to be spoken
immediately. gui_synclist_do_button calls the callback when moving up or
down to a different item. The context owning the list should call
gui_synclist_speak_item() once initially to speak the first item, and
whenever the list is changed. As a rule of thumb,
gui_synclist_speak_item() should be called in the same places where
gui_synclist_draw() is called, except that you don't want to call it
spuriously.

If the list is empty, gui_synclist_speak_item() will say something to
that effect. That alleviates the need for P#6271 (Say something when
entering an empty directory), with the bonus that it applies to any list
and not just directory browsing.

Improved hover delay: The existing strategy was simply to just wait for
half a second before saying the current filename, each and every time. I
suspect that sighted users would never tolerate the gratuitous insertion
of a half second lag in response to a key press. The strategy I
implemented uses a similar (although shorter) delay whenever we find that
a repeat keypress is received, or when movement actions are received in
quick succession. If we move to a different entry less than a quarter of
a second since we've started speaking the previous one, or if we
encounter ACTION_STD_PREVREPEAT or ACTION_STD_NEXTREPEAT, or if
next_item_modifier>1, then the overload workaround kicks in. The first
thing it does is shutup the currently speaking utterance (previously it
would continue jabbering while you scroll down your big directory). It
then schedules the speaking of the item for a bit later, much like before
(it waits a quarter second, where previously half a second was used). But
the point though is that in the default case, there's no need to wait at
all: on entering the browser, and when moving up/down slowly enough to
actually hear the beginning of the name being spoken, no artificial delay
is introduced.

I have tested this on a Sansa and found it works rather well for me. I
would particularly like feedback from someone testing this with an iPod
click wheel.

One little complication with having the hover logic in the list itself,
is that for the postponed speaking of the name to happen on time, we must
reenter gui_synclist_do_button at the appropriate time. I have
implemented a convenience function called list_do_action() which combines
get_action and gui_synclist_do_button: if the speaking of an item
pending, it shortens the get_action timeout appropriately to coincide
with the scheduled time.

 trunk/apps/gui/list.c        |   94 +++++++++++++++++++++++++++++++++++++++++--
 trunk/apps/gui/list.h        |   31 ++++++++++++++
 trunk/apps/talk.c            |    4 -
 trunk/apps/talk.h            |    1 
 trunk/apps/lang/english.lang |   14 ++++++
 5 files changed, 138 insertions(+), 6 deletions(-)