Rockbox

Tasklist

FS#2898 - token parser for wps code

Attached to Project: Rockbox
Opened by Nathan Hand (nathanh) - Monday, 09 January 2006, 12:28 GMT
Task Type Patches
Category Themes
Status Closed
Assigned To No-one
Operating System
Severity Low
Priority Normal
Reported Version Unstable (example)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

The token parser converts the tags from a WPS file to a
structured representation of the WPS. The display code
then renders the tokens rather than parsing the tags to
refresh the display. The purpose of the token parser is
to simplify the WPS code and pave the way for features
that are difficult (perhaps impossible) to implement
with the existing WPS code.
This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Tuesday, 20 March 2007, 19:25 GMT
Reason for closing:  Out of Date
Additional comments about closing:  See  FS#6862 
Comment by Nathan Hand (nathanh) - Monday, 09 January 2006, 12:47 GMT

First version of the patch is for comment and feedback only.
The code does not yet display properly so don't expect to
apply the patch and run the binary. However the skeleton of
what I want has been written so I'm throwing it out for
discussion.

The tags from the WPS file are parsed into tokens only once.
The tokens are stored in an array using a bytecode format.
Each token is either a static element (eg, a text string or
an image) or a dynamic element (eg, an ID3 tag or the time
elapsed).

The tokens are stored in z-order in the array. This means
the rendering code simply runs from 0 to num_tokens. In the
future I intend to implement bounding boxes and use dirty
regions to ensure that only elements that have been dirtied
are redrawn. That comes later, after tokens work.

Considerations that are still being worked out:

- sublines, possibly implement as conditionals with time
constraints, collapses two special cases into one.

- conditionals, I will implement each option as its own
token, the display code decides which to render.

- refresh frequency, some tokens don't need to refresh as
often, dirty regions will minimise this problem.

Comments are welcome.
Comment by Anonymous Submitter - Monday, 09 January 2006, 20:09 GMT

Do you aware of
this:http://www.rockbox.org/twiki/bin/view/Main/WPSTokenbasedHandling
Comment by Nathan Hand (nathanh) - Tuesday, 10 January 2006, 05:55 GMT

"Do you aware of this:
http://www.rockbox.org/twiki/bin/view/Main/WPSTokenbasedHandling";

Yes, of course. Stephan and I have discussed the token based
algorithm on IRC (though we both independently came to the
conclusion that it was necessary before the discussion). The
code here is similar in some ways to Stephan's algorithm,
different in other ways. The most significant difference is
that I use tokens for everything, including static text. I
see on the wiki that MatthiasM also suggested that approach.
Comment by Anonymous Submitter - Thursday, 12 January 2006, 21:05 GMT

"The most significant difference is
that I use tokens for everything, including static text. I
see on the wiki that MatthiasM also suggested that approach."
That was me :-)
And yes, I think it's good to handle everything as token.

I think the goal should be that every token can have attributes.
attribute possibility could dependend on the type of the
token (text, image, special object, are there more?). It
could be e.g. foreground color, background color, font
attributes (e.g. bold, ...), size, position, ...

So I suggest that your defined tokens (WPS_TOKEN_...) all
get one of the types (e.g. id3tag-tokens are of type text,
battery level tokens are images, ...)
Then define all possible attributes (WPS_ATTR_...) and group
them to type families (e.g. one enum per tokentype) so that
it's easy to find out which attributes are allowed for which
token.

When parsing the WPS, you have then to look for wps tags. A
wps tag is either a token itself (e.g. an id3 tag) or an
attribute. I think it would be best, when attributes
surround tokens (like in HTML).
With that we will form tokens for normal text by attributes
(e.g. when the first part of the text shall be bold and red
, the rest of the text shall be normal and green they will
form two tokens of "normal text")
Conditionals could also be attributes for tokens.

So when first parsing the WPS the list of tokens with their
attributes could be build.
Displaying the WPS just means to go through the array entry
for entry (that's what your code already does if I interpret
it correct), first looks at the conditional attributes and
then calls the correspondend display routine for the token type.

What do you think about my thoughts?
Are they just garbage or is something useful in them?

Matthias (aka Massa)

P.S.: I really appreciate that you started it - keep on
going! It's really time for a new and flexible WPS parsing
and displaying!
Comment by Anonymous Submitter - Friday, 20 January 2006, 10:16 GMT

Are you still working on it?
Comment by Anonymous Submitter - Tuesday, 24 January 2006, 00:37 GMT

Is this pretty cool project aborted? or still alive?
Comment by Nathan Hand (nathanh) - Tuesday, 24 January 2006, 05:51 GMT

"Is this pretty cool project aborted? or still alive?"

Not aborted. I've been busy with paid work and unable to
make any progress for the past few weeks. I am still
interested in completing the patch and submitting, assuming
nobody beats me to the punch.
Comment by Anonymous Submitter - Tuesday, 24 January 2006, 12:55 GMT

No one is working on it, just go ahead and finish this
promising stuff please
Comment by Anonymous Submitter - Tuesday, 07 February 2006, 23:12 GMT

Any news about this patch :(

Loading...