On Thu, 2006-01-05 at 19:22 +0000, Karl Lattimer wrote:
> > > <style>
> > > rectange#myrect {
> > > top: 25%;
> > > left: 25%;
> > > width: 50%;
> > > height: 50%;
> > > }
> > > </style>I'm certainly not opposed to css-style syntax. I think a DOM interface is overkill, and frankly not very well suited for our purposes. Truthfully, DOM is not a very nice API to work with. The first thing real JS hackers do is wrap it in something that's sane. :) But CSSish syntax is probably not a bad idea. > How about having a separate file written purely in python, but as part > of the theme package which includes all the event/condition callbacks > etc... Unlike dischi, I want to allow <script>. I don't want to dictate to theme designers how they should be coding. :) But yes, this should be allowed too: <script src="somefile.py" /> > Either way its cleaner to have a pure python solution to the > condition/event problem rather than an extract -> parse -> process model > which IMHO is far more complicated. What dischi is really after is conditionals that exist in most templating systems for html. See kid, for example: http://kid.lesscode.org/ The more I read/think about our requirements, maybe using kid (or something like it) isn't such a bad idea, rather than reinventing what's basically a template language. I do prefer the syntax of non-xml based templating systems, but something like Kid is advantageous insofar as it can be validated with xml tools. > * full control of animations from theme XML/python scripts which are > packaged together. Agreed, although to clarify I think we all agree that animations won't be specified in any xml-syntax, but using python. > * immense flexibility in the layouts, allowing for completely different > themes to be developed. We need some more discussion here, but obviously I agree. I think what I have with kaa.canvas right now will allow this. > * fully documented XML DTD, and scripting principles inc animation > examples (i'll do this) Great :) > * anamorphic themes, which work in both 16:9 and 4:3, another reason for > the python: being used wherever appropriate to the theme. I think we should only very loosely think of things in terms of 16:9 or 4:3. You can specify positions and sizes in relative values, which means all kinds of layouts are possible, including for example 30%/70% column layout, or even mixed fixed+relative layout like 250px/whatever's left. > another thing, somewhat unrelated... is it possible that when we select > a file we could have a short (audio-less) preview of the file selected > being played, picked as a scene randomly from the file. May give us an > edge. I'm not sure about "edge." MythTV does this. But it is certainly possible. Cheers, Jason.
signature.asc
Description: This is a digitally signed message part
