Jason Tackaberry wrote: >> | <container x="overscan_x1" y="overscan_y1" width="complete width - >> | overscan_x1 - overscan_x2" height="..."> >> >> Everything in this container is visible and _this_ is 4:3, independed >> of the real resolution left. So when defining > > But this is no longer 4:3. Consider a margin (overscan) of 10 pixels. > (640-20)/(480-20) = 1.347.
Yes and no. Yes, the width x height is not simple 4:3, but this is the
visible area on your screen which is 4:3 (16:9 tv sets need a 16:9
designed skin). So no matter what the real resolutiosn are, the
visible area is 4:3.
> <container left="10" top="10" right="-10" bottom="-10">
>
> (Where 10 is of course the actual overscan.)
>
> However, more appropriately, I also want to add margin and padding
> properties, so this container could be expressed using a margin:
>
> <container margin="10 10 10 10">
That's better. This simple line defines my visible area with the "10"
being a variable at startup time.
> There are 4 TODOs here:
> * calculate width/height implicitly when both left/right or both
> top/bottom is specified in position.
> * Allow negative coordinates for right/bottom (and
> hcenter/vcenter) coords.
> * Implement margin property
> * Implement padding property
>
>> | <rectangle x="25%" y="25%" width="50%" height="50%"/>
>>
>> I will get a rectangle in the visible area. 100% in this container are
>> 100% of the visible area (Tack: is that correct?)
>
> 100% in this container is the full canvas size less the overscan. I
> assume that's what you mean by "visible area" although certainly on a
> monitor, everything is visible. :)
Yes, on a monitor, but not on a tv. I onlt want to make sure that 100%
of something is everything visible no matter what the overscan
is.
>> Now take a look at the current audio menu. I want that transparent
>> area at the left outside of the screen. So how to define it? We can't
>> define it inside the container because 0% is still visible? So I need
>> to define it outside with x="0" and width="overscan_x1 +
>> 50%_of_visible_area". How to do that?
>
> So long as the container's size is not set to auto (i.e.
> "shrinkwrapped") and so long as the container is not set to clip its
> children, children are able to overflow their parent's container.
> (Setting clip="auto" on a container is equivalent to specifying
> overflow="hidden" in html)
>
> So:
>
> <container margin="10 10 10 10" >
> <image file="foo.png" left="-10" />
> </container>
>
> Because the container's size is not dependent on its children, this will
> work just fine.
Great.
>> Now I want to print some text defined in the items, e.g. the length of
>> the item.
>>
>> | <text>Length: @length@ minutes</text>
>>
>> Kaa.canvas needs a way to ask external code like Freevo what @length@
>> is. Even worse, maybe the item has no length. So it would be
>
> Right now the TextBlock object allows template variables like this. I
> could just implement this in Text objects too. It's trivial. But what
> you'd really need is something like:
>
> <text name="length">Length: @length@ minutes</text>
>
> And then Freevo will do:
>
> canvas.find_object("length").set_template_variable(length = "5:23")
Why do I need that extra name=length? I just use some variables and
set the values in a dict somewhere.
>> | <text condition="length">Length: @length@ minutes</text>
>>
>> meaning this tag is only to be proccessed if condition is True. And
>> again, kaa.canvas needs a way to check the condition using Freevo. The
>> current Freevo code checks the expressions based on the items
>> attributes.
>
> This where things get rather ugly.
I know
> The problem here is that the condition clearly can't be evaluated at
> xml-parse time. It almost seems to mean canvas objects will need a
> condition property, which isn't very elegant. I'm not sure the
> right way to implement this. I'll need to think about it.
Do that, but I guess you can see why we need that.
>> Now, to make it worse. Many texts may depend on the type of the
>> item. To avoid adding the condition again and again, it could be
>>
>> | <block condition="type == playlist>
>> | ...
>> | </block>
>> | <block condition="type == video>
>> | ...
>> | </block>
>>
>> So they whole block is only "there" if the condition is true. And when
>> you select a new item, all this needs to be checked again and stuff
>> can change.
>
> Once individual elements can handle conditions this should be easy. Is
> "condition" a python expression, or some stricter syntax?
It is much stricter. I don't want to do some 'eval' stuff without
extra checking. Kaa.canvas should call a registered function to detect
the expressions and also to get the values. Maybe just add a function
canvas.set_template_function(myfunction) and myfunction can do the
eval and the filling of the @length@ variable. I would call
canvas.re_eval() if something changed (I know when something
changed).
>> To make it more complicated I need tags of my own, like <listing> and
>> also <cover> (cover is a little bit different than a normal
>> image).
>
> This actually isn't that hard. I just need to add it to canvas.xml
Great.
>> And maybe put some stuff outside this definition. You could
>> not use a full filename in the <image> tag put a placeholder instead
>> and use <image tag="background" filename="/where/to/find"> later. So
>> just redefining this image will change the look very easy. And maybe
>> filename would not be a complete path, only a filename and kaa.canvas
>> will get a list of dirs where to search for it. When writing the xml
>> file, I don't know where images will be in the installed system.
>
> This is already possible. When you parse the xml, you can specify a
> path list:
>
> screen = kaa.canvas.get_object_from_xml(file, classname = "mainmenu",
> path=["/home/freevo/themes/default/"])
Maybe even more complex (just to make it worse). I set a variable
theme='foo' in the xml file and use image='bar.jpg' and add a path
/usr/share/freevo/themes and it will be
/usr/share/freevo/themes/foo/bar.jpg at the and. You can write a
different theme by just redefining the theme variable.
>> and if the kaa.canvas xml stuff should support all this.
>
> I think it should.
Great
>> And how to move stuff defined there later? E.g. the listing could
>> move to the left and a new one could come in from the right when
>> selecting a new dir.
>
> Yeah, new objects replacing old ones. This is further complicated the
> fact that key objects on any given screen should have specific canvas
> names so that they can be referenced programmatically. But object names
> must be unique within a canvas, so I suppose the old object will need to
> be renamed just before it goes away, and the new object will assume that
> name. Confusing and ugly. :)
It is not the problem to rename the old listing I want to move
away. The problem is that the new listing has the given coordinates as
stop value of the moving in animation.
> Another complication is that say you have an item that's within a
> container and you want to animate it outside its container, that
> animation could cause a reflow of the container, which is certainly not
> what you want. So you want to reparent the object as a child of the top
> level canvas, then animate it. But removing a child from a container
> could cause it to reflow. For an animation transition that's probably
> not what you want. So you need to be able to lock the container's size
> for moment while the new object animates in to fill its place.
Too confusing for me right now.
> One possibility is simply never animate objects this way. If you have
> an object you plan on animating, make sure it is either a direct child
> of the canvas, or that it's a child of a container that is fixed in
> size. This way you don't have the reflow problem.
No problem for me, but I'm no skin designer. :)
> Anyway, there are clearly some issues here that need to be thought out.
> Not obvious or simple stuff, and this is the kind of thing that takes 2
> rewrites to do decently. :)
:)
Well, I hope by thinking about it I only need to rewrite the gui code
once more.
Dischi
--
Black holes are where God divided by zero.
pgpf5gFbUcn8c.pgp
Description: PGP signature
