--- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > Gustavo Sverzut Barbieri wrote: > > Geoff Holden made very good icons/bg, but he disappeared! > > I still have hopes. > > > BTW, where's Krister? The last time I saw a post was a long time > ago... > > he must be bloated with work. > > I saw him two days ago on IRC, he's alive. >
good :) > >>> But we should align based on the read content or the > should-be-there > >>> content? I mean: if we have only one item in a row, where it > >>> should be 4, it should be placed on the center or at the position > >>> of the first item, as we calculate it to hold 4 items (but there > >>> is only one)? The later is the best IMO. > >> > >> Yes, the later, and we do that. > > > > Ok, how we specify that in the XML? > > I don't understand? It's always that way, you can change that. Or did > I missunderstand you? > No, I missunderstood you. :) You came with the "we do that" so quick that I think it was there before I said... :) > > Ok, it's XML bug, but as we define an area, should one be allowed > to > > draw outside that area? > > No, I will add some "if"s to prevent that later. But it's not > important, the redraw/cleaning also works if you draw outside your > area. Ok > > 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? > > Also, I think we will need text formating tags quite soon. Take a > look > > at the 3rd movie menu style. That looks too monotonous, same > colors, > > same sizes and we're loosing too much space on the screen using new > > lines to make it less mono. > > I know > > > If we have some <font> tags, which could define: family, size, > shadow, > > color, that would be very good and make our design more > interesting. > > Better to have font tags who point to already defined font objects. > So > we shouldn't name it font (because <font> is a different tag). Ok, but again you'll have to modify many things, IE: you cannot simply pass the text to osd.drawstringframed(). Since the minimum element that could have it's property changed is a char, we must have property by char? or it's better to set some attribute element that holds some text? Like this: <font label="big blue">text 1</font><font label="big red">text 2</font> text[ [font_attr[ "big blue", "text 1" ], [font_attr["big red", "text 2"] ] 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. 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. > > And we really want a <table> structure or something that let us > align > > left/center/right or top/center/down within a content. I said that > > because our new skin is very ugly just using those '\t', Everybody > > knows we should align the label to the right and the value to the > left, > > like we did before in the music player. > > Yes, we need a nice and good way to define the info text. I hate > these > @var@ and \t, too. But I want to finish the other TODO stuff first, > if > you have some free time, maybe you can hack something in > xml_parser.py > (in dischi1) and info_area. 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... :) But I'll do that 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
