From: [IDC]Dragon <idc-dragon_at_gmx.de>
Date: Tue, 30 Mar 2004 15:43:32 +0200 (MEST)

> > It's very beneficial for the voice code to have one set of IDs, not two.
> > I
> > was thinking about assigning negative IDs to the voice-only ones. So
> > they
> > could appear in the lang.h enum, but not in the lang.c array.
>
> Since we access language strings with "array[index]" everything that makes
> us
> increase the index without actually storing a useful string there is
> wasteful.
>
> I don't see how we can have them in the same array without wasting
> strings.

Again, by assigning negative values to them in the enum, growing further
into the negative range.

> > I need something that can grow in 2 directions, such that an older
> > voicefile
> > with newer software does not get all entries shifted. (That would make
> > it
> > really difficult to use ;-)
>
> It won't get shifted unless you remove voice entries, and you mustn't
> remove
> entries without chaning the voice file number, in the exact same manner
> the
> binary languages work. You don't remove language ids either.

OK. But still I have that problem with 2 sets, one for potentially voiced
strings, another for voice only entries. I'd need to introduce a second talk
function, e.g. talk_string() and talk_voice() instead of just talk_id(). I need
to know in advance which to call, the freedom gets lost. The voice file
needs two "directories", currently it has one.
Or the voice-only IDs have to get bumped into a completely different range,
this is where I suggest the negative. So I could still feed this into the
same function. Hmm, it just appeared to me that negative is not so good either,
because I use the upper bits of the ID to indicate numbers and units, with
the value in the lower bits. Very useful for option entries with numbers, so I
still need only one ID to speak the full thing. (Are you with me?)
I could modify this to not use the MSB, so negative is free.

> > >genlang checks the 'desc' field in the .lang file for the magic string
> > 'spoken
> > >only' to detect voice-only strings.
> >
> > Uh, why that? Spoken-only are those which have an empty "regular" text
> > field.
>
> No. Empty text fields in the .lang file is how we deprecate ordinary
> language
> strings. We can't assume that deprecated strings should be spoken! ;-)

Well, then empty their voice content, too.
In other words: a voice-only entry is one which has empty text, but a voice
content.

> I chose the 'spoken only' string since you had already used that on all
> strings that are spoken only and I didn't want to add any extra
> control-option
> to the file.

Certainly. I just won't rely on comments. If you don't want to check the
content, you could distinguish because I named them VOICE_xx instead of LANG_xx.

Jörg

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox

Received on 2004-03-30