[Compcomm] Animation depricating Minimize. There is one last thing that minimize can do

Erkin Bahceci erkinbah at gmail.com
Wed May 9 00:48:58 EDT 2007


Hi,

David is planning some changes on how vertices are generated and animated:
http://lists.freedesktop.org/archives/compiz/2007-April/002020.html
http://lists.freedesktop.org/archives/compiz/2007-April/002040.html

Therefore for (2), I would wait for those changes, otherwise anything
done now about that will probably have to be rewritten when he changes
how things work.

We could ask David to consider such interactions between plugins while
he's working on or planning those changes. This could be done by
putting the grid locations of vertices (where each vertex falls on the
rectangular window grid) into the core just like the vertex positions,
so that different plugins (e.g. wobbly and animation) can manipulate
the vertices (depending on those grid locations) simultaneously by
"adding" their position/orientation changes for vertices instead of
setting "absolute positions" for them. The number of vertices (or the
grid resolution) has to be set in core options in that case. I don't
know if this is what you or others want though. Any comments on this?

For (1), the velocity model "dx = f(v)" (for some function f) used by
Minimize is not "much more flexible" than just using "x = f(t)" (for
some other f). It's just a different way of doing things. It's
actually more limiting in some ways, like not being able to accurately
control the positions of points. However, I do like the springiness of
Minimize's zoom. So I can consider the springiness for some animations
(Sidekick, Zoom, and the (future) minimize variants of the fold
animations).

And about the replacing thing, the core is going to stripped off of
plugins anyways (as David said). So what do you mean by Animation
replacing Minimize? Do you mean that Animation will be distributed in
the composite community package/distribution by default instead of
Minimize? I thought that already was the plan :)

Cheers :)
Erkin


On 5/8/07, Sam Spilsbury <smspillaz at gmail.com> wrote:
> Hi. Recently there has been some discussion about the animation plugin
> replacing the minimize plugin. Most of the feature deprications are going to
> be handled or have been handled by the animation plugin itself. However
> there are two more issues.
>
> 1 Spring Model. Minimize used a spring model to control the way its
> animations worked. The animation plugin is one of the only plugins that does
> not use this. I'm not too sure what the benefits of a spring model is, but I
> know it is much more flexible than the current 'Time' system being used.
>
> 2 Minimize can transform windows that are being transformed already. This is
> pretty much essential if you don't want a conflict between wobbly and
> animation. The old minimize plugin used to be able to transform windows that
> were still wobbling (A good example of this, have :animation" and "minimize"
> on at the same time and set the minimize animation to "magic_lamp.", Also if
> you have wobbly on a low spring_k, then this happens too). The current
> animation plugin cannot do this and with ccs, the wobbly plugin is loaded
> before the animation plugin, so if focus_effect for normal windows is
> enabled, then when unminimizing windows, they appear on the screen and
> "bounce" first then if the animation is not finished it ill suddenly play
> from where it is at. I'm not too sure if solving no 1 might solve no 2.
>
> Regards
>
> SmSpillaz
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>
>



More information about the CompComm mailing list