headers
Alex Russell | 4 Apr 2005 19:08
Favicon
Gravatar

Dojo Update


New
===

* XMLHTTP transport caching support and test pages (David Schontzler, 
aka stilleye)

* Topic-based event system wrapper (Jason Carriera, Alex)

* CSS style attribute manipulation code added to htmlUtil (Dylan)

Improved
========

* POST from XMLHTTP transport fixed (Alex)

* Dylan checked in and posted a discussion he had with David which 
provides the best overview of the parsing and widget instiantiation 
systems to date. (Dylan, David)

* website updated with links to gmane instead of our b0rken pipermail 
list archives (Alex)

This Week
=========

Alex:
	* fix Content-Type for POST-ed form elements
	* more Jot-specific widgets and the fixes that fall out of them
	* take another look at why the linker is having problems with our
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Russell | 6 Apr 2005 07:14
Favicon
Gravatar

contributor license agreement


Hey everyone,

Ok, I hate this kind of licensing gunk, but the time has come for us to 
start covering our backsides with something other than our trousers. 
Specificaly copyright licensing agreements, preferably signed.

Thanks to Martin Cooper and the ASF, we've taken the Apache CLA and 
re-badged it for our purposes, and you can find it at:

	http://dojotoolkit.org/icla.txt

So, if you've submitted patches or code and would like to see me stay 
out of jail (not much of an upside, huh?), then fill that puppy out and 
fax it in. From now on, we'll be nagging you to file one of these when 
you send in a patch, but once it's on file, you never have to bother 
with that again. 

Keeping Dojo clear of IP issues is one of the biggest things we can do 
help adoption of the toolkit, and I'd like to personally say thank you 
ahead of time for making Dojo better.

Thanks and Regards

--

-- 
Alex Russell
alex <at> dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
alex <at> netWindows.org  F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
Permalink | Reply | 0 comments |
headers
David Schontzler | 7 Apr 2005 05:36
Picon

Animation

Hey all-

I was wondering what sort of animation code people would want to use
in their widgets/components/apps. And, by animation, I don't
necessarily mean something flying around the screen. The best way I've
seen animations done (Dan did it), was where you have a function that
takes an input between 0-1 and calculates the point(s) in the
animation from there. How you use the point(s) is up to you. There's
simple linear equations, bezier, etc. all with various applications.

All the animation I've done (and liked) is time-based animation. This
is nice, because animations run for the same duration independent of
CPU speed or other factors. Does anyone want to see Flash-like frame
animation capabilities as well, or is that an unnecessary addition?
Also, one thing that seems lacking from most animation code is the
ability to put a sequence of animations together trivially. You end up
having to have one's onEnd handler setup and start the next animation.
I think the ability to put animations together and just say "go" would
be awesome.

*** I'd like to get some feedback from everyone else on what they want
animations to do for them. This can be usage scenarios or more of the
innards stuff, whatever you want to say, I want to hear it. ***

(Dan, I know you have some ideas of what you'd like to do with
animations. Maybe we can collab on this a little? I'm not sure how
much time I have in the immediate future, so you can take this over if
you want to.)

Thanks,
(Continue reading)

Permalink | Reply | 16 comments |
headers
Dylan Schiemann | 7 Apr 2005 05:55

Re: Animation


SVG+SMIL has some interesting animations capabilities, with both
declarative and scripted animations.  While a lot of the SVG spec. is
overly complex, the animation stuff is fairly decent.

There's also the canvas element that apple has in Safari on Tiger, that
mozilla has been working on, and that has been discussed at the what-wg.
~ This is more of a scripted API... not declarative.

As far as what I would use it for, off the top of my head, it would be
very useful for changing the state of a widget.  For example, the
accordion widget in Flex is a popular transition.

-Dylan

David Schontzler wrote:
| Hey all-
|
| I was wondering what sort of animation code people would want to use
| in their widgets/components/apps. And, by animation, I don't
| necessarily mean something flying around the screen. The best way I've
| seen animations done (Dan did it), was where you have a function that
| takes an input between 0-1 and calculates the point(s) in the
| animation from there. How you use the point(s) is up to you. There's
| simple linear equations, bezier, etc. all with various applications.
|
| All the animation I've done (and liked) is time-based animation. This
| is nice, because animations run for the same duration independent of
| CPU speed or other factors. Does anyone want to see Flash-like frame
| animation capabilities as well, or is that an unnecessary addition?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Russell | 7 Apr 2005 06:15
Favicon
Gravatar

Re: Animation


I'm ignornant enough of animation in general that I won't stick my nose 
in the implementation details, but I do have some half-baked wants and 
concerns regarding how a widget (or app) author might USE animation.

Most of the scenarios I'm looking at today are ones where I know the 
initial state and can at least calculate the end state and want some 
kind of transition between them, be that fade in/out or clipping 
transitions (or both). Particularly, show() and hide() methods are the 
kinds of things where I need a simple way to mix in an animation 
effect. 

Unlike some other things in Dojo, it seems difficult to keep renderer 
and animation implementation very separate (am I wrong about this?), or 
come up with some kind of portable way of saying "apply this animation" 
without requiring passing in some sort of DOM Node or other rendering 
primitive to work with. If we were going to try to make things less 
renderer specific, what kind of interface might we want to enclose the 
animated primtive in? Would it be some kind of sprite? Also, would 
there be some way of applying or adding an animation declaratively? (I 
guess I don't care so much about this, but it's an interesting 
question)

I agree that putting animations end-to-end might be useful, but more 
than that, I can see a desire to composite animated effects, where a 
particular set of effects are launched at go() and all end in a 
synchronized fashion at stop() (whatever go() and stop() signify). One 
can, for instance, imagine wanting to move an element into place on 
some sort of bezier function and at the same time fade it in based on 
some kind of linear function.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Aaron Boodman | 7 Apr 2005 06:34
Picon

Re: Animation

> > All the animation I've done (and liked) is time-based animation.

I usually tend toward this as well. However, I think it warrants
another look. I believe that the original impetus for this approach
was the wide divergence in animation performance between platforms.
Put another way: does anyone use Win 9x anymore?

>> a particular set of effects are launched at go() and all end in a
synchronized
>> fashion at stop() 

Not to pimp my own code, but to go ahead and pimp my own code, of all
the javascript I've ever written, Accelimation is among the bits I
reuse most often. It did the above really, really easily.

var a1 = new Accelimation(thing, propName, 0, 50, 300);
var a2 = new Accelimation(thing, propName, 0, 50, 300);
a1.start();
a2.start();

--

-- 
Aaron
Permalink | Reply | 13 comments |
headers
David Schontzler | 7 Apr 2005 09:23
Picon

Re: Animation

Dylan said:
> SVG+SMIL has some interesting animations capabilities, with both
> declarative and scripted animations.  While a lot of the SVG spec. is
> overly complex, the animation stuff is fairly decent.
> 
> There's also the canvas element that apple has in Safari on Tiger, that
> mozilla has been working on, and that has been discussed at the what-wg.
> ~ This is more of a scripted API... not declarative.

Good point. Might as well build off some good minds.

Alex said:
> One
> can, for instance, imagine wanting to move an element into place on
> some sort of bezier function and at the same time fade it in based on
> some kind of linear function.

Yes, that's a perfectly legitimate want/need. Animations should be
setup to be N-dimensional, so handling coordinates and a fade between
colors could be 3-D (x, y, color) or even 5-D (x, y, r, g, b). The
animation stuff should be pretty flexible and, off that, I think we
could put together some pre-built animation stuff.

Aaron said:
> Not to pimp my own code, but to go ahead and pimp my own code, of all
> the javascript I've ever written, Accelimation is among the bits I
> reuse most often. It did the above really, really easily.

I'll have to take another look at your code. I remember when I saw it
that I liked what it did, but that Dan's had some bits that were
(Continue reading)

Permalink | Reply | 2 comments |
headers
Aaron Boodman | 7 Apr 2005 09:57
Picon

Re: Animation

Yeah, I remember Dan's being better as well. This is one thing I'm
pretty interested in; I'll keep an ear on it.
Permalink | Reply | 1 comment |
headers
David Schontzler | 7 Apr 2005 10:18
Picon

Re: Animation

On Apr 7, 2005 12:57 AM, Aaron Boodman <zboogs <at> gmail.com> wrote:
> Yeah, I remember Dan's being better as well. This is one thing I'm
> pretty interested in; I'll keep an ear on it.

I think the "big thing" was that his was setup for N-dimension stuff
and you could do some pretty crazy things, so long as you can write a
function that responds well to to the form foo(0..1).
Permalink | Reply | 0 comments |
headers
Erik Arvidsson | 7 Apr 2005 10:56

Re: Animation

Aaron Boodman wrote:
> Not to pimp my own code, but to go ahead and pimp my own code, of all
> the javascript I've ever written, Accelimation is among the bits I
> reuse most often. It did the above really, really easily.
> 
> var a1 = new Accelimation(thing, propName, 0, 50, 300);
> var a2 = new Accelimation(thing, propName, 0, 50, 300);
> a1.start();
> a2.start();

This format is very flexible (I use my own SimpleAnimator class in the 
same way ;-) ) but when designing an API I would without a doubt go for 
the SMIL model. I started implementing a SMIL engine in JS a long time 
ago. I didn't get too far but I'll try to dig it out and see what state 
it is in.

erik
Permalink | Reply | 9 comments |

Gmane