On Wed, 5 Jan 2011 15:14:25 -0200 Gustavo Sverzut Barbieri
> On Wed, Jan 5, 2011 at 2:36 PM, Carsten Haitzler <raster@...> wrote:
> > On Wed, 5 Jan 2011 12:48:05 -0200 Gustavo Sverzut Barbieri
> > <barbieri@...> said:
> >> On Wed, Jan 5, 2011 at 12:27 PM, ChunEon Park <chuneon.park@...>
> >> wrote:
> >> > Good day, this is Hermet.
> >> >
> >> > Here is elm_transit patch.
> >> >
> >> > - Modified elm_transit_add(double duration) to elm_transit_add()
> >> > - Added elm_transit_duration_set() / elm_transit_duration_get() APIs
> >> > - Added elm_transit_go API
> >> Modifying the duration of an ongoing animation is tricky, what do you
> >> do to avoid things going weirdly? Let's say you're at 0.5 of an 1.0
> >> second (progress = 50%), then you reset it to 2.0 second, you're now
> >> back in progress to 25%.
> >> I'm also strongly against _go() apis. They do not need to exist, as
> >> they don't for all but elm_list, which is there for an optimization
> >> hack which I dislike every time i have to type them.
> > in this case transit is a time based thing - when does it start its
> > animation? you can do a lot of set-up before you start it and thus there is
> > a good reason for being able to separate the starting of the transition
> > from its setup. as for setting the duration - not weird - not more weird
> > than the adding ofthe objects. if you stand back and look at it, transit is
> > much like an object - u create it then set up a whole bunch of properties
> > (basically a transition pipeline) and then say "go". there is no good
> > reason why it shouldn't be expanded to allow chained transitions. eg
> > transition from A to B, then B to C, then C to D - and thus there would be
> > a good case for each leg of the transition to have its own timeframe - thus
> > a set call for setting the transition duration. again - this also makes the
> > go() call almost a must as at what point would you start that transition -
> > and for that matter if you have a fairly lengthy and complex transition you
> > do often you may want to repeat it again and again (call go to start it
> > each time).
> It's just not like any of other efl, ecore primitives, for instance.
> If you need something else, just create a new one. The "lots of setup"
> does not buy, hardly you'll go back to main loop and start the
> animation later on.
o = evas_object_image_add(e);
evas_object_move(o, 100, 100);
evas_object_resize(o, 200, 100);
evas_object_image_file_set(o, "blah.png", NULL);
evas_object_image_fill_set(o, 200, 100);
not a lot of setup? :) it's the same thing - conceptually.
> But anyway, as you said before nobody is using this code except by
> you, so it is an external babbler pointing at others stuff. If you
> disagree with me just commit it and I'll not complain, but I had to
> state that I'm against this kind of alien apis.
actually the api still is different - but how it is now isnt good either - like
the show() - when does the animation start? have you looked at the tests where
they set up several transtions (a fade and a rotate and a translate?) which one
starts it? you can call quite a few things before you are done setting it up...
(for flip u need to add 2 objects and then set up the flip). so it is actually
a whole series of setup calls.
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> MSN: barbieri@...
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...