ChunEon Park | 1 Dec 2010 01:17

[E-devel] [Patch] elm_animator

Please check this small patch. 
Added one miner API. 

Thanks. 

The Hermet 

Index: elm_animator.c
===================================================================
--- elm_animator.c	(revision 55099)
+++ elm_animator.c	(working copy)
 <at>  <at>  -38,11 +38,11  <at>  <at> 
    double duration;
    unsigned int repeat_cnt;
    unsigned int cur_repeat_cnt;
-   double (*curve_op) (double frame);
    void (*animator_op) (void *data, Elm_Animator *animator, double frame);
    void *animator_arg;
    void (*completion_op) (void *data);
    void *completion_arg;
+   Elm_Animator_Curve_Style curve_style;
    Eina_Bool auto_reverse:1;
    Eina_Bool on_animating:1;
 };
 <at>  <at>  -111,7 +111,24  <at>  <at> 
    animator->cur_time = ecore_loop_time_get();
    elapsed_time = animator->cur_time - animator->begin_time;
    if (elapsed_time > animator->duration) elapsed_time = animator->duration;
(Continue reading)

Gustavo Sverzut Barbieri | 1 Dec 2010 01:23

Re: [E-devel] E SVN: bdilly trunk/TMP/st/elementary/src/lib

On Tuesday, November 30, 2010, Daniel Juyung Seo <seojuyung2 <at> gmail.com> wrote:
>>
>>  By: WooHyun Jung <wh0705.jung <at> samsung.com>
>>
>
> k-s: see some one else is motivated :)

Yeah! Keep rocking!

>
>
> On Wed, Dec 1, 2010 at 3:53 AM, Enlightenment SVN
> <no-reply <at> enlightenment.org> wrote:
>> Log:
>> Improve elm_colorselector readability and fix clicked entry sig emission
>>
>>  The reason for modifying about elm_colorselector can be "readability".
>>  Each bar in the colorselector has its own color type (like hue, saturation,
>>  ...)
>>  So I thought it will be better, if I added enum for each color type.
>>
>>  And, for about elm_entry.c , I thought that "SIG_CLICKED" was wrongly
>>  emitted (by "MOUSE_UP" event).
>>  I deleted mouse_up callback function (as you advised),
>>  because this function didn't do anything by my modification.
>>
>>  By: WooHyun Jung <wh0705.jung <at> samsung.com>
>>
>>
>> Author:       bdilly
(Continue reading)

Eduardo Felipe | 1 Dec 2010 01:28
Picon
Gravatar

Re: [E-devel] Simpler animator.

Sorry, no elm_* for me.

Were I work we are restricted to Edje, Ecore, Evas, *. No Elementary. :(

On Tue, Nov 30, 2010 at 8:49 PM, Gustavo Sverzut Barbieri
<barbieri <at> profusion.mobi> wrote:
> On Tue, Nov 30, 2010 at 8:20 PM, Eduardo Felipe
> <eduardofelipe87 <at> gmail.com> wrote:
>> Hi folks,
>>
>> I'm starting a thread to discuss the idea of a simpler ecore_animator.
>> My idea is to have a time based API that just calls a callback over a
>> period of time and pass as a pass a float from 0.0 to 1.0 to the it,
>> so one could animate things like "turn white in two seconds" easier.
>> I know it's completely possible to do this, and quite easy actually,
>> but I keep having to implement this over and over to animate little
>> like a clipper's color and I'm beginning to wonder if this should be
>> in 1.1.
>> Mind you that raster wrote such a thing for his edje_lua2 API (he
>> called it "transition" to match EDC) and I think such a transition API
>> would be nice. What do you think?
>
> You want elm_transit ;-)
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbieri <at> gmail.com
> Skype: gsbarbieri
(Continue reading)

Gustavo Sverzut Barbieri | 1 Dec 2010 01:46

Re: [E-devel] Simpler animator.

On Tuesday, November 30, 2010, Eduardo Felipe <eduardofelipe87 <at> gmail.com> wrote:
> Sorry, no elm_* for me.
>
> Were I work we are restricted to Edje, Ecore, Evas, *. No Elementary. :(

Tooooo bad, you're loosing great bits. But that code is not dependent
on other elm bits, just copy it over. It will not be replicated at
other efl libs.

> On Tue, Nov 30, 2010 at 8:49 PM, Gustavo Sverzut Barbieri
> <barbieri <at> profusion.mobi> wrote:
>> On Tue, Nov 30, 2010 at 8:20 PM, Eduardo Felipe
>> <eduardofelipe87 <at> gmail.com> wrote:
>>> Hi folks,
>>>
>>> I'm starting a thread to discuss the idea of a simpler ecore_animator.
>>> My idea is to have a time based API that just calls a callback over a
>>> period of time and pass as a pass a float from 0.0 to 1.0 to the it,
>>> so one could animate things like "turn white in two seconds" easier.
>>> I know it's completely possible to do this, and quite easy actually,
>>> but I keep having to implement this over and over to animate little
>>> like a clipper's color and I'm beginning to wonder if this should be
>>> in 1.1.
>>> Mind you that raster wrote such a thing for his edje_lua2 API (he
>>> called it "transition" to match EDC) and I think such a transition API
>>> would be nice. What do you think?
>>
>> You want elm_transit ;-)
>>
>> --
(Continue reading)

ChunEon Park | 1 Dec 2010 01:55

Re: [E-devel] [Patch] elm_animator

Please look at this patch file. 
The previous may not be applied properly. 

Thanks. 

The Hermet

-----Original Message-----
From: ChunEon Park [mailto:chuneon.park <at> samsung.com] 
Sent: Wednesday, December 01, 2010 9:18 AM
To: 'enlightenment-devel <at> lists.sourceforge.net'
Subject: [E-devel] [Patch] elm_animator 

Please check this small patch. 
Added one miner API. 

Thanks. 

The Hermet 

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
(Continue reading)

Eduardo Felipe | 1 Dec 2010 02:07
Picon
Gravatar

Re: [E-devel] Simpler animator.

Well, thanks anyway.

Eduardo.

On Tue, Nov 30, 2010 at 10:46 PM, Gustavo Sverzut Barbieri
<barbieri <at> profusion.mobi> wrote:
> On Tuesday, November 30, 2010, Eduardo Felipe <eduardofelipe87 <at> gmail.com> wrote:
>> Sorry, no elm_* for me.
>>
>> Were I work we are restricted to Edje, Ecore, Evas, *. No Elementary. :(
>
> Tooooo bad, you're loosing great bits. But that code is not dependent
> on other elm bits, just copy it over. It will not be replicated at
> other efl libs.
>
>
>> On Tue, Nov 30, 2010 at 8:49 PM, Gustavo Sverzut Barbieri
>> <barbieri <at> profusion.mobi> wrote:
>>> On Tue, Nov 30, 2010 at 8:20 PM, Eduardo Felipe
>>> <eduardofelipe87 <at> gmail.com> wrote:
>>>> Hi folks,
>>>>
>>>> I'm starting a thread to discuss the idea of a simpler ecore_animator.
>>>> My idea is to have a time based API that just calls a callback over a
>>>> period of time and pass as a pass a float from 0.0 to 1.0 to the it,
>>>> so one could animate things like "turn white in two seconds" easier.
>>>> I know it's completely possible to do this, and quite easy actually,
>>>> but I keep having to implement this over and over to animate little
>>>> like a clipper's color and I'm beginning to wonder if this should be
>>>> in 1.1.
(Continue reading)

ChunEon Park | 1 Dec 2010 03:17

Re: [E-devel] [Patch] elm_animator

Sorry, missed the patch file.
Attached it again. 

Thanks. 

The Hermet 

-----Original Message-----
From: ChunEon Park [mailto:chuneon.park <at> samsung.com] 
Sent: Wednesday, December 01, 2010 9:56 AM
To: 'enlightenment-devel <at> lists.sourceforge.net'
Subject: RE: [E-devel] [Patch] elm_animator 

Please look at this patch file. 
The previous may not be applied properly. 

Thanks. 

The Hermet

-----Original Message-----
From: ChunEon Park [mailto:chuneon.park <at> samsung.com] 
Sent: Wednesday, December 01, 2010 9:18 AM
To: 'enlightenment-devel <at> lists.sourceforge.net'
Subject: [E-devel] [Patch] elm_animator 

Please check this small patch. 
Added one miner API. 

Thanks. 
(Continue reading)

ChunEon Park | 1 Dec 2010 03:45

[E-devel] [Patch] elm_transit

Hi, This is Hermet

Because original elm_transit had event blocking for the objects in default, 

it had two APIs - elm_transit_event_block_disabled_set,
elm_transit_event_block_disabled_get.

But the concept is modified to no-event-blocking in default when it is
contributed. 

So the APIs was changed to elm_transit_event_block_set,
elm_transit_event_block_get also. 

Designing the transit for the temporary effect, I think that blocking-event
mode is more used then non-blocking generally. 

Additionally, a few applications are using original elm_transit already in
our platform, 

I hope to re-back if it does not really necessary. 

Could you please consider my proposal to re-back the concept?

I attached the small patch file. 

Thanks. 

Index: elm_transit.c
(Continue reading)

Mike Blumenkrantz | 1 Dec 2010 03:48
Favicon

Re: [E-devel] E SVN: discomfitor trunk/ecore/src/lib/ecore

On Tue, 30 Nov 2010 18:34:49 -0800
"Enlightenment SVN" <no-reply <at> enlightenment.org> wrote:

> Log:
> switch to EINA_BOOL values for delete_me, fix huge O(n) behavior in
> _ecore_main_fd_handlers_call; all fd operations now should see an exponential
> speed increase based on the number of fds that ecore is watching 
> 
> Author:       discomfitor
> Date:         2010-11-30 18:34:48 -0800 (Tue, 30 Nov 2010)
> New Revision: 55102
> Trac:         http://trac.enlightenment.org/e/changeset/55102
> 
> Modified:
>   trunk/ecore/src/lib/ecore/ecore_main.c 
> 
> Modified: trunk/ecore/src/lib/ecore/ecore_main.c
> ===================================================================
> --- trunk/ecore/src/lib/ecore/ecore_main.c	2010-12-01 01:17:45 UTC
> (rev 55101) +++ trunk/ecore/src/lib/ecore/ecore_main.c	2010-12-01
> 02:34:48 UTC (rev 55102)  <at>  <at>  -119,10 +119,14  <at>  <at> 
>  static Eina_List        *fd_handlers_with_buffer = NULL;
>  static Eina_List        *fd_handlers_to_delete = NULL;
>  
> +static Eina_List        *fd_handlers_to_call = NULL;
> +static Eina_List        *fd_handlers_to_call_current;
> +static Eina_List        *fd_handlers_to_call_current_next;
> +
>  #ifdef _WIN32
>  static Ecore_Win32_Handler *win32_handlers = NULL;
(Continue reading)

Vincent Torri | 1 Dec 2010 06:07
Picon

Re: [E-devel] E SVN: discomfitor trunk/ecore/src/lib/ecore


On Tue, 30 Nov 2010, Enlightenment SVN wrote:

> Log:
> switch to EINA_BOOL values for delete_me, fix huge O(n) behavior in _ecore_main_fd_handlers_call; all
fd operations now should see an exponential speed increase based on the number of fds that ecore is watching

next time, split the commit into several parts (eina bool, then the speed 
increase)

Vincent

>
>
> Author:       discomfitor
> Date:         2010-11-30 18:34:48 -0800 (Tue, 30 Nov 2010)
> New Revision: 55102
> Trac:         http://trac.enlightenment.org/e/changeset/55102
>
> Modified:
>  trunk/ecore/src/lib/ecore/ecore_main.c
>
> Modified: trunk/ecore/src/lib/ecore/ecore_main.c
> ===================================================================
> --- trunk/ecore/src/lib/ecore/ecore_main.c	2010-12-01 01:17:45 UTC (rev 55101)
> +++ trunk/ecore/src/lib/ecore/ecore_main.c	2010-12-01 02:34:48 UTC (rev 55102)
>  <at>  <at>  -119,10 +119,14  <at>  <at> 
> static Eina_List        *fd_handlers_with_buffer = NULL;
> static Eina_List        *fd_handlers_to_delete = NULL;
>
(Continue reading)


Gmane