--- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > 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. >
Ok > > 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> > But if we do the thing like I said, we almost have a HTML render. I mean render, not parser. However you could make a parser that translate the data to the render's format. Also, if we have kind of HTML parser/render. The INFO area could be an external .html, so people could also use it in their browser. > > 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 I think the same way as above. > > 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. I'll try to implement that using n-cols and some things like an HTML table: cellpadding, cellspacing, widht=<interger>|<percentage>, height=... However, if that's too difficult, I'll follow your adivice :) > > But I'll do that > > Cool. Feel free to change it inside dischi1. Ok. But give me some points on where to change and about your new draw functions (as you said, they don't draw anything directly, only a dummy draw and later it draws on the screen) Also, would be interesting if I could render the tables to a surface and we could use that surface later. I'm planning a Email reader as soon as I have a basic HTML render. For things like that: a static text, we should render the whole thing to a surface and just get part of it to blit on the screen, like a side-scrolling game. Gustavo _______________________________________________________________________ Yahoo! Mail O melhor e-mail gratuito da internet: 6MB de espa�o, antiv�rus, acesso POP3, filtro contra spam. http://br.mail.yahoo.com/ ------------------------------------------------------- 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
