[E-devel] [Patch] elm_genlist pan changed patch
Dear EFL Developers This patch is to fix the problem that blinking is occured when application use the ecore timer and the rendering delay at pan resize/move using evas_object_smart_changed instead of ecore_job_add. Thanks chanwook jung elm_genlist_patch.diff Description: Binary data -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn trunk/elementary/src/lib
Hello Tom,
Thanks for you fix.
I have one question here.
I think this macro has no big benefit.
+#define BASE(it) (&(it)->base)
There is no much difference between "BASE(it)" and "it->base".
But there are two macros for base.view and base.widget in elm_widget.h
#define VIEW(X) X->base.view
#define WIDGET(X) X->base.widget
If BASE macro is necessary, the best place is elm_widget.h.
Thank you.
Daniel Juyung Seo (SeoZ)
On Wed, Dec 7, 2011 at 9:56 PM, Enlightenment SVN
wrote:
> Log:
> Elm toolbar: Fix brokeness introduced by commit 65708.
>
> Disabled is a property of Elm_Object_Item and was a property of
> Elm_Toolbar_Item as well. The aforementioned commit didn't remove the
> property from the latter and then used both properties in an
> inconsistent manner which caused data not to be up to date.
>
> Author: tasn
> Date: 2011-12-07 04:56:34 -0800 (Wed, 07 Dec 2011)
> New Revision: 65989
> Trac: http://trac.enlightenment.org/e/changeset/65989
>
> Modified:
> trunk/elementary/src/lib/elm_toolbar.c
>
> Modified: trunk/elementary/src/lib/elm_toolbar.c
> ===
> --- trunk/elementary/src/lib/elm_toolbar.c 2011-12-07 12:07:44 UTC (rev
> 65988)
> +++ trunk/elementary/src/lib/elm_toolbar.c 2011-12-07 12:56:34 UTC (rev
> 65989)
> @@ -4,6 +4,10 @@
> #include "els_box.h"
> #include "els_icon.h"
>
> +/* FIXME: I couldn't find a macro for it, this should be fixed.
> + * Just doing this commit to fix the brokeness that was introduced. */
> +#define BASE(it) (&(it)->base)
> +
> typedef struct _Widget_Data Widget_Data;
> typedef struct _Elm_Toolbar_Item Elm_Toolbar_Item;
>
> @@ -40,7 +44,6 @@
> Eina_Bool visible : 1;
> } prio;
> Eina_Bool selected : 1;
> - Eina_Bool disabled : 1;
> Eina_Bool separator : 1;
> Eina_Bool menu : 1;
> Eina_List *states;
> @@ -150,7 +153,7 @@
> Eina_Bool sel;
>
> if (!wd) return;
> - if ((it->disabled) || (it->separator)) return;
> + if ((BASE(it)->disabled) || (it->separator)) return;
> sel = it->selected;
>
> if (!wd->no_select)
> @@ -223,9 +226,9 @@
> Widget_Data *wd = elm_widget_data_get(WIDGET(it));
>
> if (!wd) return;
> - if (it->disabled == disabled) return;
> - it->disabled = !!disabled;
> - if (it->disabled)
> + if (BASE(it)->disabled == disabled) return;
> + BASE(it)->disabled = !!disabled;
> + if (BASE(it)->disabled)
> {
> edje_object_signal_emit(VIEW(it), "elm,state,disabled", "elm");
> elm_widget_signal_emit(it->icon, "elm,state,disabled", "elm");
> @@ -317,7 +320,7 @@
> edje_object_signal_emit(view, "elm,state,selected", "elm");
> elm_widget_signal_emit(it->icon, "elm,state,selected", "elm");
> }
> - if (it->disabled)
> + if (BASE(it)->disabled)
> {
> edje_object_signal_emit(view, "elm,state,disabled", "elm");
> elm_widget_signal_emit(it->icon, "elm,state,disabled", "elm");
> @@ -540,7 +543,7 @@
> menu_it = elm_menu_item_add(menu, NULL,
> it->icon_str, it->label,
> _elm_toolbar_item_menu_cb,
> it);
> - elm_object_item_disabled_set(menu_it,
> it->disabled);
> + elm_object_item_disabled_set(menu_it,
> BASE(it)->disabled);
> if (it->o_menu)
> elm_menu_clone(it->o_menu, menu, menu_it);
> }
> @@ -732,7 +735,7 @@
> Elm_Toolbar_Item *it = (Elm_Toolbar_Item *)item;
> if (it->separator)
> return strdup(E_("Separator"));
> - else if (it->disabled)
> + else if (BASE(it)->disabled)
> return strdup(E_("State: Disabled"));
> else if (it->selected)
> return strdup(E_("State: Selected"));
> @@ -1763,7 +1766,7 @@
> wd->icon_size,
> "elm,state,icon_set,backward");
> }
> - if (item->disabled)
> + if (BASE(item)->disabled)
> elm_widget_signal_emit(item->icon, "elm,state,disabled", "elm");
> else
> elm_widget_signal_emit(item->icon, "elm,state,enabled", "elm");
>
>
> --
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Cloud Services Checklist:
Re: [E-devel] E SVN: yoz IN trunk/elementary/src: bin lib
Thanks a lot!
I made some changes on there. Latest changes need to come first.
Dear all e-devs, please update ElementaryChanges wiki page if you
change elementary APIs or whatever.
Thanks.
Daniel Juyung Seo (SeoZ)
On Wed, Dec 7, 2011 at 11:41 PM, michael bouchaud
wrote:
> done
>
> 2011/12/7 Daniel Juyung Seo
>
>> This is cool!!
>> Please update ElementaryChanges wiki page for elementary API or
>> whatever changes.
>> http://trac.enlightenment.org/e/wiki/ElementaryChanges
>>
>> I just saw the elm_index code and there are a lot to be fixed in elm_index
>> :(
>> This will be done soon :)
>>
>> Thanks.
>> Daniel Juyung Soe (SeoZ)
>>
>> On Tue, Dec 6, 2011 at 11:05 PM, Enlightenment SVN
>> wrote:
>> > Log:
>> > elementary: API break ! using Elm_Index_Item instead of the item's data
>> in the index widget. This was applied for function and smart callbacks
>> >
>> > Author: yoz
>> > Date: 2011-12-06 06:05:55 -0800 (Tue, 06 Dec 2011)
>> > New Revision: 65956
>> > Trac: http://trac.enlightenment.org/e/changeset/65956
>> >
>> > Modified:
>> > trunk/elementary/src/bin/test_index.c trunk/elementary/src/lib/
>> Elementary.h.in trunk/elementary/src/lib/elm_index.c
>> >
>> > Modified: trunk/elementary/src/bin/test_index.c
>> > ===
>> > --- trunk/elementary/src/bin/test_index.c 2011-12-06 11:36:29 UTC
>> (rev 65955)
>> > +++ trunk/elementary/src/bin/test_index.c 2011-12-06 14:05:55 UTC
>> (rev 65956)
>> > @@ -20,7 +20,7 @@
>> > {
>> > // called on a change but delayed in case multiple changes happen in a
>> > // short timespan
>> > - elm_genlist_item_top_bring_in(event_info);
>> > + elm_genlist_item_top_bring_in(elm_index_item_data_get(event_info));
>> > }
>> >
>> > void
>> > @@ -34,7 +34,7 @@
>> > index_selected(void *data __UNUSED__, Evas_Object *obj __UNUSED__, void
>> *event_info)
>> > {
>> > // called on final select
>> > - elm_genlist_item_top_bring_in(event_info);
>> > + elm_genlist_item_top_bring_in(elm_index_item_data_get(event_info));
>> > }
>> >
>> > void
>> > @@ -160,13 +160,15 @@
>> > Test_Index2_Elements *gui = data;
>> > const char *label, *label_next;
>> > Elm_List_Item *it, *it_next;
>> > + Elm_Index_Item *iit;
>> >
>> > it = elm_list_selected_item_get(obj);
>> > it_next = elm_list_item_next(it);
>> >
>> > if (!it_next)
>> > {
>> > - elm_index_item_del(gui->id, it);
>> > + iit = elm_index_item_find(gui->id, it);
>> > + if (iit) elm_index_item_del(gui->id, iit);
>> > elm_list_item_del(it);
>> > return;
>> > }
>> > @@ -174,14 +176,11 @@
>> > label = elm_list_item_label_get(it);
>> > label_next = elm_list_item_label_get(it_next);
>> >
>> > + iit = elm_index_item_find(gui->id, it);
>> > if (label[0] == label_next[0])
>> > - {
>> > - Elm_Index_Item *iit;
>> > - iit = elm_index_item_find(gui->id, it);
>> > - elm_index_item_data_set(iit, it_next);
>> > - }
>> > + elm_index_item_data_set(iit, it_next);
>> > else
>> > - elm_index_item_del(gui->id, it);
>> > + elm_index_item_del(gui->id, iit);
>> >
>> > elm_list_item_del(it);
>> > }
>> > @@ -189,7 +188,7 @@
>> > void
>> > test_index2_id_changed(void *data __UNUSED__, Evas_Object *obj
>> __UNUSED__, void *event_info)
>> > {
>> > - elm_list_item_show(event_info);
>> > + elm_list_item_show(elm_index_item_data_get(event_info));
>> > }
>> >
>> > void
>> >
>> > Modified: trunk/elementary/src/lib/Elementary.h.in
>> > ===
>> > --- trunk/elementary/src/lib/Elementary.h.in 2011-12-06 11:36:29 UTC
>> (rev 65955)
>> > +++ trunk/elementary/src/lib/Elementary.h.in 2011-12-06 14:05:55 UTC
>> (rev 65956)
>> > @@ -22399,19 +22399,14 @@
>> > EAPI int elm_index_item_level_get(const Evas_Object *obj)
>> EINA_ARG_NONNULL(1);
>> >
>> > /**
>> > - * Returns the last selected item's data, for a given index widget.
>> > + * Returns the last selected item, for a given index widget.
>> > *
>> > * @param obj The index object.
>> > - * @return The item @b data associated to the last selected item on
>> > - * @p obj (or @c NULL, on errors).
>> > + * @return The last item @b selected on @p obj (or @c NULL, on
>> errors).
>> > *
>> > - * @warning The returned value is @b not an #Elm_Index_Item item
>> > - * handle, but the data associated to it (see the @c item parameter
>> > - * in elm_index_item_append(), as an example).
>> > - *
>> > * @ingroup Index
>> > */
>> > - EAPI void *elm_index_item_selected_get(const Evas_Object
>> *obj, int level) EINA_ARG_NONNULL(1);
>> > + EAPI Elm_Index_Item *elm_index_item_selected_get(const Evas_Object
>> *obj, int level) EINA_ARG_NONNULL(1);
>> >
>> > /**
>> > * Append a new item on a given index widget.
>> > @@ -22456,8 +22451,7 @@
>> > * @param obj
Re: [E-devel] E SVN: seoz IN trunk/PROTO/azy/src: bin include
please follow that rule of thumb: first, config.h then standard headers then dependencies headers then EFL headers in the order of dependency of course Vincent On Thu, Dec 8, 2011 at 12:14 AM, Enlightenment SVN < no-re...@enlightenment.org> wrote: > Log: > azy: Added appropriate headers. Fixed build break. > > > Author: seoz > Date: 2011-12-07 15:14:29 -0800 (Wed, 07 Dec 2011) > New Revision: 65999 > Trac: http://trac.enlightenment.org/e/changeset/65999 > > Modified: > trunk/PROTO/azy/src/bin/azy.h trunk/PROTO/azy/src/include/Azy.h > > Modified: trunk/PROTO/azy/src/bin/azy.h > === > --- trunk/PROTO/azy/src/bin/azy.h 2011-12-07 22:52:34 UTC (rev 65998) > +++ trunk/PROTO/azy/src/bin/azy.h 2011-12-07 23:14:29 UTC (rev 65999) > @@ -7,6 +7,7 @@ > #define AZY_H > > #include > +#include > > #ifndef strdupa > # define strdupa(str) strcpy(alloca(strlen(str) + 1), str) > > Modified: trunk/PROTO/azy/src/include/Azy.h > === > --- trunk/PROTO/azy/src/include/Azy.h 2011-12-07 22:52:34 UTC (rev 65998) > +++ trunk/PROTO/azy/src/include/Azy.h 2011-12-07 23:14:29 UTC (rev 65999) > @@ -21,6 +21,7 @@ > > #include > #include > +#include > > #ifdef EAPI > # undef EAPI > > > > -- > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point > of > discussion for anyone considering optimizing the pricing and packaging > model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/exactness: . data data/recording src src/bin src/lib src/scripts
On Wed, 07 Dec 2011 22:32:51 +0200 Tom Hacohen wrote: > On 07/12/11 19:12, Leandro Pereira wrote: > > On 12/06/2011 02:05 PM, Enlightenment SVN wrote: > >> Modified: trunk/exactness/tasn_is_a_lazy_bastard > >> === > >> --- trunk/exactness/tasn_is_a_lazy_bastard 2011-12-06 15:52:11 UTC > >> (rev 65960) +++ trunk/exactness/tasn_is_a_lazy_bastard 2011-12-06 > >> 16:05:14 UTC (rev 65961) @@ -1 +1 @@ > >> -And he deserves to DIEE > >> +And he deserves to live forever. > > > > Unrelated change, please revert. > > Look closely at the file, it obviously states I'm a lazy bastard, no way > I'm going to split my commits properly. > > -- > Tom. > well if you won't do it then I will -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/exactness: . data data/recording src src/bin src/lib src/scripts
On 07/12/11 19:12, Leandro Pereira wrote: > On 12/06/2011 02:05 PM, Enlightenment SVN wrote: >> Modified: trunk/exactness/tasn_is_a_lazy_bastard >> === >> --- trunk/exactness/tasn_is_a_lazy_bastard 2011-12-06 15:52:11 UTC (rev >> 65960) >> +++ trunk/exactness/tasn_is_a_lazy_bastard 2011-12-06 16:05:14 UTC (rev >> 65961) >> @@ -1 +1 @@ >> -And he deserves to DIEE >> +And he deserves to live forever. > > Unrelated change, please revert. Look closely at the file, it obviously states I'm a lazy bastard, no way I'm going to split my commits properly. -- Tom. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/exactness: . data data/recording src src/bin src/lib src/scripts
On 12/06/2011 02:05 PM, Enlightenment SVN wrote: > Modified: trunk/exactness/tasn_is_a_lazy_bastard > === > --- trunk/exactness/tasn_is_a_lazy_bastard2011-12-06 15:52:11 UTC (rev > 65960) > +++ trunk/exactness/tasn_is_a_lazy_bastard2011-12-06 16:05:14 UTC (rev > 65961) > @@ -1 +1 @@ > -And he deserves to DIEE > +And he deserves to live forever. Unrelated change, please revert. Leandro -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: yoz IN trunk/elementary/src: bin lib
done
2011/12/7 Daniel Juyung Seo
> This is cool!!
> Please update ElementaryChanges wiki page for elementary API or
> whatever changes.
> http://trac.enlightenment.org/e/wiki/ElementaryChanges
>
> I just saw the elm_index code and there are a lot to be fixed in elm_index
> :(
> This will be done soon :)
>
> Thanks.
> Daniel Juyung Soe (SeoZ)
>
> On Tue, Dec 6, 2011 at 11:05 PM, Enlightenment SVN
> wrote:
> > Log:
> > elementary: API break ! using Elm_Index_Item instead of the item's data
> in the index widget. This was applied for function and smart callbacks
> >
> > Author: yoz
> > Date: 2011-12-06 06:05:55 -0800 (Tue, 06 Dec 2011)
> > New Revision: 65956
> > Trac: http://trac.enlightenment.org/e/changeset/65956
> >
> > Modified:
> > trunk/elementary/src/bin/test_index.c trunk/elementary/src/lib/
> Elementary.h.in trunk/elementary/src/lib/elm_index.c
> >
> > Modified: trunk/elementary/src/bin/test_index.c
> > ===
> > --- trunk/elementary/src/bin/test_index.c 2011-12-06 11:36:29 UTC
> (rev 65955)
> > +++ trunk/elementary/src/bin/test_index.c 2011-12-06 14:05:55 UTC
> (rev 65956)
> > @@ -20,7 +20,7 @@
> > {
> >// called on a change but delayed in case multiple changes happen in a
> >// short timespan
> > - elm_genlist_item_top_bring_in(event_info);
> > + elm_genlist_item_top_bring_in(elm_index_item_data_get(event_info));
> > }
> >
> > void
> > @@ -34,7 +34,7 @@
> > index_selected(void *data __UNUSED__, Evas_Object *obj __UNUSED__, void
> *event_info)
> > {
> >// called on final select
> > - elm_genlist_item_top_bring_in(event_info);
> > + elm_genlist_item_top_bring_in(elm_index_item_data_get(event_info));
> > }
> >
> > void
> > @@ -160,13 +160,15 @@
> >Test_Index2_Elements *gui = data;
> >const char *label, *label_next;
> >Elm_List_Item *it, *it_next;
> > + Elm_Index_Item *iit;
> >
> >it = elm_list_selected_item_get(obj);
> >it_next = elm_list_item_next(it);
> >
> >if (!it_next)
> > {
> > - elm_index_item_del(gui->id, it);
> > +iit = elm_index_item_find(gui->id, it);
> > +if (iit) elm_index_item_del(gui->id, iit);
> >elm_list_item_del(it);
> >return;
> > }
> > @@ -174,14 +176,11 @@
> >label = elm_list_item_label_get(it);
> >label_next = elm_list_item_label_get(it_next);
> >
> > + iit = elm_index_item_find(gui->id, it);
> >if (label[0] == label_next[0])
> > - {
> > - Elm_Index_Item *iit;
> > - iit = elm_index_item_find(gui->id, it);
> > - elm_index_item_data_set(iit, it_next);
> > - }
> > + elm_index_item_data_set(iit, it_next);
> >else
> > - elm_index_item_del(gui->id, it);
> > + elm_index_item_del(gui->id, iit);
> >
> >elm_list_item_del(it);
> > }
> > @@ -189,7 +188,7 @@
> > void
> > test_index2_id_changed(void *data __UNUSED__, Evas_Object *obj
> __UNUSED__, void *event_info)
> > {
> > - elm_list_item_show(event_info);
> > + elm_list_item_show(elm_index_item_data_get(event_info));
> > }
> >
> > void
> >
> > Modified: trunk/elementary/src/lib/Elementary.h.in
> > ===
> > --- trunk/elementary/src/lib/Elementary.h.in2011-12-06 11:36:29 UTC
> (rev 65955)
> > +++ trunk/elementary/src/lib/Elementary.h.in2011-12-06 14:05:55 UTC
> (rev 65956)
> > @@ -22399,19 +22399,14 @@
> >EAPI int elm_index_item_level_get(const Evas_Object *obj)
> EINA_ARG_NONNULL(1);
> >
> >/**
> > -* Returns the last selected item's data, for a given index widget.
> > +* Returns the last selected item, for a given index widget.
> > *
> > * @param obj The index object.
> > -* @return The item @b data associated to the last selected item on
> > -* @p obj (or @c NULL, on errors).
> > +* @return The last item @b selected on @p obj (or @c NULL, on
> errors).
> > *
> > -* @warning The returned value is @b not an #Elm_Index_Item item
> > -* handle, but the data associated to it (see the @c item parameter
> > -* in elm_index_item_append(), as an example).
> > -*
> > * @ingroup Index
> > */
> > - EAPI void *elm_index_item_selected_get(const Evas_Object
> *obj, int level) EINA_ARG_NONNULL(1);
> > + EAPI Elm_Index_Item *elm_index_item_selected_get(const Evas_Object
> *obj, int level) EINA_ARG_NONNULL(1);
> >
> >/**
> > * Append a new item on a given index widget.
> > @@ -22456,8 +22451,7 @@
> > * @param obj The index object.
> > * @param letter Letter under which the item should be indexed
> > * @param item The item data to set for the index's item
> > -* @param relative The item data of the index item to be the
> > -* predecessor of this new one
> > +* @param relative The index item to be the predecessor of this new
> one
> > *
> > * Despite the most common usage of the @p letter argum
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 7, 2011 at 9:06 AM, Cedric BAIL wrote: > On Wed, Dec 7, 2011 at 11:50 AM, Vincent Torri > wrote: >> On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger >> wrote: >>> On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: >>> > On 12/06/11 20:10, Enlightenment SVN wrote: >>> > > Log: >>> > > NO! you break api. you made my e sit here with a segv in a getenv. >>> > > because now many libraries and api's don't have prototyopes for >>> > > malloc/calloc and much more and this goes horribly wrong especially >>> on >>> > > 64bit! the eina headers have provided these includes historically >>> and >>> > > removing them is a BREAK in api. apps that used to compile and run >>> > > just fine now don't. it's unacceptable to break api. >>> > > >>> > > i'm stuck here in unity for crying out loud! this deservves a big >>> FAT >>> > > REVERT for that! :-P >>> > > >>> > AHMEN !!! To force ANYONE into Unity, is just extra pain that "we" >>> > should not have to go through. Raster, I am with you on this one >>> > regardless of the reason. To force something to use Unity is pain >>> > enough...the fact that EFL in general would break this much is not >>> > acceptible...period. >>> >>> Seriously, if you don't stop compilation on missing prototypes, you are >>> doing something wrong. I do not consider this to be an API breakage. >>> Headers should include just what they need -- e.g. if they directly use >>> a type or macro. >>> >> >> I agree. The eina header should just be self consistent (i mean : include >> what is really necessary). If no stdlib.h stuff is used in the headers, >> then stdlib.h can be removed. It's the source file including the eina >> header that is not including a necessary header file > > That was my point of view to, but raster is right. As people using EFL > weren't require to include in there file, they didn't. > Changing this, break their apps, so it's an API break. That's sad and > bad, but there is little we can do. For 2.0, in 10 years, we can fix > that, but now we are stuck with this include. I agree... Though it would be better not to include them, once it's there there's not much we can do. Lucas De Marchi -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, 7 Dec 2011 12:06:46 +0100 Cedric BAIL said: > On Wed, Dec 7, 2011 at 11:50 AM, Vincent Torri > wrote: > > On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger >> wrote: > >> On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: > >> > On 12/06/11 20:10, Enlightenment SVN wrote: > >> > > Log: > >> > > NO! you break api. you made my e sit here with a segv in a getenv. > >> > > because now many libraries and api's don't have prototyopes for > >> > > malloc/calloc and much more and this goes horribly wrong especially > >> on > >> > > 64bit! the eina headers have provided these includes historically > >> and > >> > > removing them is a BREAK in api. apps that used to compile and run > >> > > just fine now don't. it's unacceptable to break api. > >> > > > >> > > i'm stuck here in unity for crying out loud! this deservves a big > >> FAT > >> > > REVERT for that! :-P > >> > > > >> > AHMEN !!! To force ANYONE into Unity, is just extra pain that "we" > >> > should not have to go through. Raster, I am with you on this one > >> > regardless of the reason. To force something to use Unity is pain > >> > enough...the fact that EFL in general would break this much is not > >> > acceptible...period. > >> > >> Seriously, if you don't stop compilation on missing prototypes, you are > >> doing something wrong. I do not consider this to be an API breakage. > >> Headers should include just what they need -- e.g. if they directly use > >> a type or macro. > >> > > > > I agree. The eina header should just be self consistent (i mean : include > > what is really necessary). If no stdlib.h stuff is used in the headers, > > then stdlib.h can be removed. It's the source file including the eina > > header that is not including a necessary header file > > That was my point of view to, but raster is right. As people using EFL > weren't require to include in there file, they didn't. > Changing this, break their apps, so it's an API break. That's sad and > bad, but there is little we can do. For 2.0, in 10 years, we can fix > that, but now we are stuck with this include. correct. if this is good or bad (we include stdlib.h and what not) is now irrelevant. applications depend on that feature - even our OWN efl libs (efreet, ecore etc. etc.) rely on it - thus me being grumpily stuck in unity with e barfing at some weird place - getenv(). reality is anyone else using eina may end up in a similar position and that makes for an api break - if we like it or not, it's compatibility we have to maintain. we can change it at 2.0 when we are allowed to break things - but until that day ... we can't :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_conform patch
2011/12/7 PRINCE KUMAR DUBEY : > The problem is how focus will pass from parent through conformant (an edje > object) to its children and vice-versa. The same way the elm_layout does it internally? > Thanks. > --- Original Message --- > Sender : ??? > Date : Dec 07, 2011 07:41 (GMT+05:30) > Title : RE: Re: [E-devel] [Patch] elm_conform patch > > Hello ~ Prince. > > With current elm_conformant's codes, focus tree doesn't have any problem > because, > every content, which is set by elm_conformant_content_set_func, will be a > sub-object of elm_conformant. > (you can check elm_widget_sub_object_add in _content_set_hook function) > > I cannot remember well but we've discussed about this patch long time before. > So can I know the exact problem about this focus-fixing patch ? > > Thanks. > -Original Message- > From: "Carsten Haitzler" > To: prince.du...@samsung.com > Cc: "Enlightenment developer list" > Sent: 11-12-07(?) 09:00:31 > Subject: Re: [E-devel] [Patch] elm_conform patch > On Tue, 06 Dec 2011 14:48:16 + (GMT) PRINCE KUMAR DUBEY > said: > >> May be I didn't explain the problem properly. >> The issue is: >> focus is not traversing from parent window through conformant to its content >> or vice versa. Since, conformant is an edje object, focus chain breaks here. >> For that, I added elm_layout widget so, in widget hierarchy focus can >> traverse from top(or bottom) to bottom(or top) through conformant. > > yes - and that's a hack. most widgets in elm are/have edje objects and they > handle passing focus to the child via a function. look at > _elm_frame_focus_next_hook() in elm_frame.c - the passing focus to the layout > is a "fallback" for ultra simple widgets that just stuff elm widgets directly > as children. there is an edje object in between here. just add that func into > conformant and register it, don't add a layout in addition to the current edje > obj. > >> Thanks, >> Prince >> --- Original Message --- >> Sender : Carsten Haitzler >> Date : Dec 06, 2011 15:10 (GMT+05:30) >> Title : Re: [E-devel] [Patch] elm_conform patch >> >> On Tue, 06 Dec 2011 18:31:48 +0900 ChunEon Park said: >> >> i'd say - don't use anything. elm_conformant should be doing this by itself >> just like layout, box, frame etc. manage it too. >> >> > Then use a box. Box does not need more style and simple to use. >> > Thank you. >> > >> > -Regards, Hermet- >> > >> > -Original Message- >> > From: "Carsten Haitzler" >> > To: "Enlightenment developer >> > list" Cc: "PRINCE KUMAR >> > DUBEY" Sent: 11-12-06(?) 18:17:21 >> > Subject: Re: [E-devel] [Patch] elm_conform patch >> > On Fri, 25 Nov 2011 13:06:27 + (GMT) PRINCE KUMAR DUBEY >> > said: >> > > >> > > Hi, >> > > >> > > Attachment to the mail is elm_conform patch. >> > > Change Log: >> > > 1. Focus chain issue fix by inserting elm_layout in hierarchy . >> > i think this is a bit of a hack... i don't like this. so reject because of >> > this. i think conformant is just not handling focus next/hook stuff right. >> > look at other widgets for example (eg frame). >> > > 2. When no geometry information of indicator/softkey/keyboard, resetting >> > > the geometry. >> > i could accept this bit of the patch if you split it. or re-submit with >> > above stuff fixed/improved :) >> > > Please review it. >> > > I'd appreciate any comments on this. >> > > >> > > Thank you, >> > > Prince >> > -- >> > - Codito, ergo sum - "I code, therefore I am" -- >> > The Rasterman (Carsten Haitzler) ras...@rasterman.com >> > -- >> > Cloud Services Checklist: Pricing and Packaging Optimization >> > This white paper is intended to serve as a reference, checklist and point >> > of discussion for anyone considering optimizing the pricing and packaging >> > model of a cloud services business. Read Now! >> > http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> > ___ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- >> > Cloud Services Checklist: Pricing and Packaging Optimization >> > This white paper is intended to serve as a reference, checklist and point >> > of discussion for anyone considering optimizing the pricing and packaging >> > model of a cloud services business. Read Now! >> > http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> > ___ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> -- >> - Codito, ergo sum - "I code, therefore I am" -- >> The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- > ---
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 7, 2011 at 11:50 AM, Vincent Torri wrote: > On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger > wrote: >> On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: >> > On 12/06/11 20:10, Enlightenment SVN wrote: >> > > Log: >> > > NO! you break api. you made my e sit here with a segv in a getenv. >> > > because now many libraries and api's don't have prototyopes for >> > > malloc/calloc and much more and this goes horribly wrong especially >> on >> > > 64bit! the eina headers have provided these includes historically >> and >> > > removing them is a BREAK in api. apps that used to compile and run >> > > just fine now don't. it's unacceptable to break api. >> > > >> > > i'm stuck here in unity for crying out loud! this deservves a big >> FAT >> > > REVERT for that! :-P >> > > >> > AHMEN !!! To force ANYONE into Unity, is just extra pain that "we" >> > should not have to go through. Raster, I am with you on this one >> > regardless of the reason. To force something to use Unity is pain >> > enough...the fact that EFL in general would break this much is not >> > acceptible...period. >> >> Seriously, if you don't stop compilation on missing prototypes, you are >> doing something wrong. I do not consider this to be an API breakage. >> Headers should include just what they need -- e.g. if they directly use >> a type or macro. >> > > I agree. The eina header should just be self consistent (i mean : include > what is really necessary). If no stdlib.h stuff is used in the headers, > then stdlib.h can be removed. It's the source file including the eina > header that is not including a necessary header file That was my point of view to, but raster is right. As people using EFL weren't require to include in there file, they didn't. Changing this, break their apps, so it's an API break. That's sad and bad, but there is little we can do. For 2.0, in 10 years, we can fix that, but now we are stuck with this include. -- Cedric BAIL -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 7, 2011 at 10:48 AM, Joerg Sonnenberger wrote: > On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: > > On 12/06/11 20:10, Enlightenment SVN wrote: > > > Log: > > > NO! you break api. you made my e sit here with a segv in a getenv. > > >because now many libraries and api's don't have prototyopes for > > >malloc/calloc and much more and this goes horribly wrong especially > on > > >64bit! the eina headers have provided these includes historically > and > > >removing them is a BREAK in api. apps that used to compile and run > > >just fine now don't. it's unacceptable to break api. > > > > > >i'm stuck here in unity for crying out loud! this deservves a big > FAT > > >REVERT for that! :-P > > > > > AHMEN !!! To force ANYONE into Unity, is just extra pain that "we" > > should not have to go through. Raster, I am with you on this one > > regardless of the reason. To force something to use Unity is pain > > enough...the fact that EFL in general would break this much is not > > acceptible...period. > > Seriously, if you don't stop compilation on missing prototypes, you are > doing something wrong. I do not consider this to be an API breakage. > Headers should include just what they need -- e.g. if they directly use > a type or macro. > I agree. The eina header should just be self consistent (i mean : include what is really necessary). If no stdlib.h stuff is used in the headers, then stdlib.h can be removed. It's the source file including the eina header that is not including a necessary header file Vincent -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: > On 12/06/11 20:10, Enlightenment SVN wrote: > > Log: > > NO! you break api. you made my e sit here with a segv in a getenv. > >because now many libraries and api's don't have prototyopes for > >malloc/calloc and much more and this goes horribly wrong especially on > >64bit! the eina headers have provided these includes historically and > >removing them is a BREAK in api. apps that used to compile and run > >just fine now don't. it's unacceptable to break api. > > > >i'm stuck here in unity for crying out loud! this deservves a big FAT > >REVERT for that! :-P > > > AHMEN !!! To force ANYONE into Unity, is just extra pain that "we" > should not have to go through. Raster, I am with you on this one > regardless of the reason. To force something to use Unity is pain > enough...the fact that EFL in general would break this much is not > acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. Joerg -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] edje_entry double click word selection
Dear MJ, Thanks a lot for the patch, this is a very needed feature, however I have a couple of comments on the implementation. The reason I was postponing implementing word selection for entry, is that it's not that trivial. There's a complete standard on word boundaries that has to be implemented (http://unicode.org/reports/tr29/#Word_Boundaries) for it to work correctly for all languages. I'm not against implementing an incomplete implementation (i.e one that just filters according to some chars) until we get around to doing the complete implementation, but in that case, edje_object_part_text_word_separators_set must be removed, as it won't be useful in the future. We need to make the incomplete implementation look like a complete implementation and just behave differently in the details. Personally, I prefer having an implementation inside textblock as it has more information, something like: "cursor_to_word_end" and "cursor_to_word_start". Also, I can see you changed the way _curs_back behaves, but judging from the textblock code, your change is not needed as it's already like that there... Also, I don't see how it relates to your change because a paragraph separator is a word separator anyway. The comments above are especially relevant for languages that don't use spaces that often, or that break words without hyphens. I believe that using the line breaking algorithm (that we already have) will give better results than working with delimiters (although it won't be perfect itself). In conclusion, I wouldn't mind applying a patch that just automatically handles this (without exposing any API to the user) as first step towards a complete implementation, but I do believe implementing it inside textblock as described above is a better solution. Therefore, this patch can't be applied in it's current form, but needs to be adjusted as Vincent suggested in his mails, and as I suggested above. Waiting to hear your thoughts on the matter. -- Tom. On 07/12/11 05:52, Myungjae Lee wrote: > Dear, Tom, Raster and EFL people. > > Now I'm trying to reduce the code diffs between EFL svn and my company's > local git repository. > I'm sending you entry-related patches continuously those are specialized in > mobile environment such as selection handlers and magnifier. > > First, I attached edje entry patch for double click word selection. > > It can be applied in all current entry selection modes (default and > explicit mode). > But at this moment default mode has some bugs with scrollers due to > 'EVAS_EVENT_FLAGS_ON_HOLD' event flag, and in the explicit mode canceling > selection is not as familiar as other word processor. Therefore current > word selection is just same with selecting word by clicking select > contextual menu and dragging mouse to the end of the word. > > This can be improved with selection mode later and triple click line > selection also can be added in a similar way. > I added an API (edje_object_part_text_word_separators_set) to control word > separators in an application. > > Please review this patch and apply it if it's acceptable. > Or if you have any opinion for this feel free to give me a feedback. > > Thanks. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compilation and Environment
On Wed, Dec 7, 2011 at 9:38 AM, P Purkayastha wrote: > Isn't this already present in some form here: > http://trac.enlightenment.org/e/wiki/Packaging Oh, I didn't see that this page get so much updated. Very nice. Now need to merge information. Thanks for the link. -- Cedric BAIL -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compilation and Environment
Isn't this already present in some form here: http://trac.enlightenment.org/e/wiki/Packaging -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/exactness: . data data/recording src src/bin src/lib src/scripts
Hello Mr. Daniel Juyung Seo (SeoZ) My name is Aharon and I'm responsible for exactness. Tested it just now with 'exactness -r', it worked as expected. I would appreciate it if you FWD more information to me. You can run: LD_PRELOAD=/opt/e17/lib/exactness/libexactness.so gdb exactness_raw Then in gdb prompt do: r --record if you still get segv, please send me the back trace. You intending to do recording to ALL widgets? This what it will do when running it without parameters. Please review the README file for more info. Thank you, Aharon Hillel. On Wed, 2011-12-07 at 09:14 +0900, Daniel Juyung Seo wrote: > SOUNDS AWESOME! > But I can't test it :( I got segv when I ran 'exactness -r' > Anyhow, this is so nice and every widget developer have to use it and > test with it. > Thanks. > > Daniel Juyung Seo (SeoZ) > > On Wed, Dec 7, 2011 at 1:05 AM, Enlightenment SVN > wrote: > > Log: > > Exactness: initial commit. > > > > (Commit message by TAsn): > > Exactness is a pixel perfect test suite for elm/evas/edje. > > Exactness lets you write tests, and then record a specific interaction > > with them, while taking windowshots in the process. The tests can later > > be played back (windowshots will be automatically taken) and the > > pictures will be compared for differences (usage of fail_if is also > >supported). > > There is a premade set of tests and recordings for all (most?) of the > > elementary widgets in various scenarios. > > Because of the nature of this test suite, it doesn't handle well any > > tests with continued running animations/viedos (timing can never be 100% > >right). But you can use it to test widgets with transition > > animations. Bottom line: just give it a go. > > > > Read the README for more inforamtion. > > > > I hope it'll be deployed on our servers soon, as we really need > > automatic testing. > > > > Signed-off-by: Aharon Hillel > > > > Author: tasn > > Date: 2011-12-06 08:05:14 -0800 (Tue, 06 Dec 2011) > > New Revision: 65961 > > Trac: http://trac.enlightenment.org/e/changeset/65961 > > > > Added: > > trunk/exactness/AUTHORS trunk/exactness/COPYING trunk/exactness/ChangeLog > > trunk/exactness/INSTALL trunk/exactness/Makefile.am trunk/exactness/NEWS > > trunk/exactness/README trunk/exactness/autogen.sh > > trunk/exactness/configure.ac trunk/exactness/data/ > > trunk/exactness/data/recording/ trunk/exactness/data/recording/test_3d.rec > > trunk/exactness/data/recording/test_actionslider.rec > > trunk/exactness/data/recording/test_anchorblock.rec > > trunk/exactness/data/recording/test_anchorview.rec > > trunk/exactness/data/recording/test_bg_image.rec > > trunk/exactness/data/recording/test_bg_options.rec > > trunk/exactness/data/recording/test_bg_plain.rec > > trunk/exactness/data/recording/test_box_horiz.rec > > trunk/exactness/data/recording/test_box_vert.rec > > trunk/exactness/data/recording/test_bubble.rec > > trunk/exactness/data/recording/test_button.rec > > trunk/exactness/data/recording/test_calendar.rec > > trunk/exactness/data/recording/test_check.rec > > trunk/exactness/data/recording/test_colorselector.rec > > trunk/exactness/data/recording/test_conformant.rec > > trunk/exactness/data/recording/test_conformant2.rec > > trunk/exactness/data/recording/test_ctxpopup.rec > > trunk/exactness/data/recording/test_diskselector.rec > > trunk/exactness/data/recording/test_fileselector.rec > > trunk/exactness/data/recording/test_fileselector_button.rec > > trunk/exactness/data/recording/test_fileselector_entry.rec > > trunk/exactness/data/recording/test_focus.rec > > trunk/exactness/data/recording/test_gengrid.rec > > trunk/exactness/data/recording/test_genlist.rec > > trunk/exactness/data/recording/test_genlist10.rec > > trunk/exactness/data/recording/test_genlist11.rec > > trunk/exactness/data/recording/test_genlist2.rec > > trunk/exactness/data/recording/test_genlist3.rec > > trunk/exactness/data/recording/test_genlist4.rec > > trunk/exactness/data/recording/test_genlist6.rec > > trunk/exactness/data/recording/test_genlist8.rec > > trunk/exactness/data/recording/test_grid.rec > > trunk/exactness/data/recording/test_hover.rec > > trunk/exactness/data/recording/test_hover2.rec > > trunk/exactness/data/recording/test_hoversel.rec > > trunk/exactness/data/recording/test_index.rec > > trunk/exactness/data/recording/test_inwin.rec > > trunk/exactness/data/recording/test_inwin2.rec > > trunk/exactness/data/recording/test_label.rec > > trunk/exactness/data/recording/test_list.rec > > trunk/exactness/data/recording/test_notify.rec > > trunk/exactness/data/recording/test_pager_slide.rec > > trunk/exactness/data/recording/test_panel.rec > > trunk/exactness/data/recording/test_panes.rec > > trunk/exactness/data/recording/test_progressbar.rec > > trunk/exactness/data/recording/test_radio.rec > > trunk/exactness/data/recording/test_scaling.rec > > trunk/exactness/data/recording
