On Thu, 2006-01-05 at 14:22 +0100, Dirk Meyer wrote: > | <canvas style="video menu"> > | <image name="background" width="100%" height="100%"/> > > so now we have a background filling the whole screen, now we define > the "visible" area.
Yep.
> | <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.
This isn't really a problem. We shouldn't require a specific aspect
ratio. We shouldn't be positioning items by fixed coordinate but rather
by percentages of their container.
Note that right now it's not possible to specify both left and right,
and both top and bottom, but it will be (it's on my mental TODO), so the
width/height will automatically be computed by that. So your overscan
container will (once I code it) be possible like this:
<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">
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. :)
> 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.
> 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")
> | <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. 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.
> 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?
> 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
> 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/"])
> That is my basic idea. Now I need to know if it would be possible with
> kaa.canvas in general
Should be. Or will be. :)
> and if the kaa.canvas xml stuff should support all this.
I think it should.
> 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. :)
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.
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. But then it also
restricts how you can layout the screen and/or what you can animate on
it (or at least how you can animate it). Still, in the short term at
least, we should try to do this, because it's easier. So if you have an
item of a vbox, you're not going to animate a single item outside that
box.
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. :)
Jason.
signature.asc
Description: This is a digitally signed message part
