Gustavo Sverzut Barbieri wrote:
>> > And about the <if> tags? It's working? I was wondering how to
>> implement
>> > that, since the <if condition=""> must be evaluated not at parse
>> time,
>> > but when you will use it's content. How are you dealing with that?
>> > Also, where in the new skin we get the XML contents and give them
>> to
>> > the OSD?
>>
>> I haven't started on that. The xml_parser.py should parse it to some
>> python code to eval (or something else, but not xml anymore) and
>> store
>> that in the XML_content object (IIRC self.cdata right now). When
>> needed info_area.py has to evaluate the conditions.
>
> Ok... but how that will be inserted around text? You'll have to modify
> the structure and create an array of elements, some elements are text
> other are clauses with text, I'm right?
I think so. But only the info area uses cdata, so you won't break
anything by chaging it. Just parse the xml file in xml_parser and
change the drawing routine in info_area.py.
> However I vote for the first option, cause we can avoid nested
> elements, like <font><font></font></font>. This could be an hell if we
> go recursive... and if we eliminate it doing something like:
> <a><b></b></b> == <a></a><b></b></a> it's not ok too, IMO.
No, it's too complicated. But a <font> defines the family, the size
and the color. So you could use
<some-tag-name font="my big yellow font">Title</some-tag-name>
<hskip(or whatever)><get variable="title">
and later in the xml file you define
<font label="my big yellow font">how the font looks</font>
> If we follow the first scheme, we could have one text attribute which
> could set each char element, like font family, size, color, shadow
> (others?). If we find nested tags, what we have to do is override the
> attrs. We handle the worst case (all the chars have different attrs)
> and the best. That wouldn't be slow since we didn't draw that much text
> on the screen.
No tags in tags. It's complicated enough already. Only <if> and <get>
can be inside eachother and the font <some-tag-name> inside <if> and
<get> inside this tag.
> Ok, but how to handle tables? It's the worst part IMHO. We will have to
> calculate the size of each table cell, check if that fits on the
> screen, if not width/n_cols, then calculate the height, same... it's a
> pain... :)
Just stick to two cols, that should be enough (like Title:
blah). Right now if there is a tab (\t) align it, if there is no tab,
use the whole width for this line. I need that to write the long plot
info for movies and write the smaller ons in table style. And it
doesn't matter if you can't break the line if the second part is too
long.
> But I'll do that
Cool. Feel free to change it inside dischi1.
Dischi
--
Veni, Vidi, VISA:
I came, I saw, I did a little shopping.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
