Re: [E-devel] Evas 3d, Eina matrix, Ector, etc...
On 7 January 2016 at 09:59, Cedric BAIL wrote:
> Hello,
>
> On Tue, Jan 5, 2016 at 10:04 PM, Jean-Philippe André
> wrote:
> > Recently a series of patches for Evas 3d and Evas VG have been merged in
> > (mostly by Cedric and myself), and add a bunch of new APIs as well as
> EAPI
> > symbols.
> >
> > I also accepted two patches and forgot to push them yesterday before the
> > freeze:
> > 1. 996d17bcc5a08e75f evas: Update Ector_Color structure
> > 2. d2bb0eefc4a2eb640 Evas 3d: Get hash table of scenes using the given
> node
> > as root.
> >
> > If you find them not acceptable for this release, please revert (patch 1.
> > is probably fine... but see below).
> >
> >
> > None of the Ector APIs are stable.
> >
> >
> > So, this raises a few questions:
> > - Should eina_vector{2,3} be static inline in the header instead of EAPI?
> > (less symbols)
>
> I think so.
>
That's done (static inline, no EAPI)
Eina_Vector3 has not been merged in EFL. I guess this will wait until 1.18?
Or do we want them now for 1.17? (for consistency... but i don't like the
idea of rushing this in)
See https://phab.enlightenment.org/D3527
(it still needs to be inlined anyway)
>
> > - Should we even install the Ector headers?
>
They are not installed anymore. So the next point must be fixed :)
> > - Should Ector_Color be Efl.Gfx.Color instead? Or Eina? (I argued myself
> > that color belonged to ector, but now I wonder, considering ector is not
> > stable)
>
> I have been thinking they should belong to Efl.Gfx.Color in fact as we
> do have API to set color in Efl.Gfx and it would make sense to make
> this compatible with that structure. I may do that change tomorrow if
> nobody raise their voice on the matter.
>
Ok, I'll let you do that then. Thanks.
--
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 3d, Eina matrix, Ector, etc...
Hello.
On 07/01/16 10:09, Jean-Philippe André wrote:
> On 7 January 2016 at 09:59, Cedric BAIL wrote:
>
>> Hello,
>>
>> On Tue, Jan 5, 2016 at 10:04 PM, Jean-Philippe André
>> wrote:
>>> Recently a series of patches for Evas 3d and Evas VG have been merged in
>>> (mostly by Cedric and myself), and add a bunch of new APIs as well as
>> EAPI
>>> symbols.
>>>
>>> I also accepted two patches and forgot to push them yesterday before the
>>> freeze:
>>> 1. 996d17bcc5a08e75f evas: Update Ector_Color structure
>>> 2. d2bb0eefc4a2eb640 Evas 3d: Get hash table of scenes using the given
>> node
>>> as root.
>>>
>>> If you find them not acceptable for this release, please revert (patch 1.
>>> is probably fine... but see below).
>>>
>>>
>>> None of the Ector APIs are stable.
>>>
>>>
>>> So, this raises a few questions:
>>> - Should eina_vector{2,3} be static inline in the header instead of EAPI?
>>> (less symbols)
>> I think so.
>>
> That's done (static inline, no EAPI)
Thanks for this.
> Eina_Vector3 has not been merged in EFL. I guess this will wait until 1.18?
> Or do we want them now for 1.17? (for consistency... but i don't like the
> idea of rushing this in)
>
> See https://phab.enlightenment.org/D3527
>
> (it still needs to be inlined anyway)
Please do not rush this in. We have so many things already and without
an internal user for it we should really not put it in after the freeze.
regards
Stefan Schmidt
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1
Hello, On 7 January 2016 at 03:38, Cedric BAIL wrote: > > > [...] > > Edje_Common.h > > edje_size_class_list ( ) > I'm not a fan of this. It's just like text_class and color_class, so fine, but I think an iterator would have been better. Consistency is important, though. > > edje_mmap_size_class_iterator_new ( Eina_File* f ) > > edje_mmap_text_class_iterator_new ( Eina_File* f ) > > edje_size_class_active_iterator_new ( ) > > edje_text_class_active_iterator_new ( ) > OK, so those APIs are in fact useless right now. They return an iterator to a private struct: Edje_Size_Class or Edje_Text_Class. A few solutions: - Make those structs public and STABLE - Keep them opaque but add APIs to inspect them (eg. edje_size_class_iterator_item_name_get() , edje_size_class_iterator_item_del() ...) - Remove these APIs (they return a different set than the class_list functions) Also, what about EO and bindings here? What do you guys think? All those APIs need test cases btw. > > Edje_Legacy.h > > edje_object_size_class_del ( Evas_Object* obj, char const* size_class ) > > edje_object_text_class_del ( Evas_Object* obj, char const* text_class ) > > I am fine with all the above one. > Are those necessary? Adding legacy APIs for new things. No EO equivalent? > eina_value.h > > eina_value_optional_empty_is ( Eina_Value const* value, Eina_Bool* > > is_empty ) > > eina_value_optional_empty_new ( ) > > eina_value_optional_type_get ( Eina_Value* value )> > eina_value_optional_new ( Eina_Value_Type const* subtype, void const* > > value ) > > eina_value_optional_pget ( Eina_Value* value, void* subvalue ) > > eina_value_optional_pset ( Eina_Value* value, Eina_Value_Type const* > > subtype, void const* subvalue ) > > eina_value_optional_reset ( Eina_Value* value ) > > EINA_VALUE_TYPE_OPTIONAL [data] > So those optional values are really just values that may be unset? I'm not sure why a normal eina_value can't just have the empty property, and have a void type that stores nothing. Did I miss something? > > eina_matrix.h > > eina_matrix2_array_set ( Eina_Matrix2* m, double const* v ) > > eina_matrix2_copy ( Eina_Matrix2* dst, Eina_Matrix2 const* src ) > > eina_matrix2_identity ( Eina_Matrix2* m ) > > eina_matrix2_inverse ( Eina_Matrix2* out, Eina_Matrix2 const* mat ) > > eina_matrix2_multiply ( Eina_Matrix2* out, Eina_Matrix2 const* mat_a, > > Eina_Matrix2 const* mat_b ) > > eina_matrix2_multiply_copy ( Eina_Matrix2* out, Eina_Matrix2 const* > > mat_a, Eina_Matrix2 const* mat_b ) > > eina_matrix2_type_get ( Eina_Matrix2 const* m ) > > eina_matrix2_values_get ( Eina_Matrix2 const* m, double* xx, double* xy, > > double* yx, double* yy ) > > eina_matrix2_values_set ( Eina_Matrix2* m, double xx, double xy, double > > yx, double yy ) > > eina_matrix3_array_set ( Eina_Matrix3* m, double const* v ) > > eina_matrix3_copy ( Eina_Matrix3* dst, Eina_Matrix3 const* src ) > > eina_matrix3_multiply ( Eina_Matrix3* out, Eina_Matrix3 const* mat_a, > > Eina_Matrix3 const* mat_b ) > > eina_matrix3_multiply_copy ( Eina_Matrix3* out, Eina_Matrix3 const* > > mat_a, Eina_Matrix3 const* mat_b ) > > eina_matrix3_position_transform_set ( Eina_Matrix3* out, double const > > p_x, double const p_y ) > > eina_matrix3_scale_transform_set ( Eina_Matrix3* out, double s_x, double > > s_y ) > > eina_matrix4_array_set ( Eina_Matrix4* m, double const* v ) > > eina_matrix4_copy ( Eina_Matrix4* dst, Eina_Matrix4 const* src ) > > eina_matrix4_multiply_copy ( Eina_Matrix4* out, Eina_Matrix4 const* > > mat_a, Eina_Matrix4 const* mat_b ) > > eina_matrix4_ortho_set ( Eina_Matrix4* m, double left, double right, > > double bottom, double top, double dnear, double dfar ) > > eina_normal3_matrix_get ( Eina_Matrix3* out, Eina_Matrix4 const* m ) > > > > eina_quaternion.h > > eina_quaternion_angle_plains ( Eina_Quaternion* a, Eina_Quaternion* b ) > > eina_quaternion_array_set ( Eina_Quaternion* dst, double const* v ) > > eina_quaternion_copy ( Eina_Quaternion* dst, Eina_Quaternion const* src ) > > eina_quaternion_distance_get ( Eina_Quaternion const* a, Eina_Quaternion > > const* b ) > > eina_quaternion_distance_square_get ( Eina_Quaternion const* a, > > Eina_Quaternion const* b ) > > eina_quaternion_homogeneous_regulate ( Eina_Quaternion* out, > > Eina_Quaternion const* v ) > > eina_quaternion_inverse ( Eina_Quaternion* out, Eina_Quaternion const* q > ) > > eina_quaternion_length_get ( Eina_Quaternion const* v ) > > eina_quaternion_length_square_get ( Eina_Quaternion const* v ) > > eina_quaternion_subtract ( Eina_Quaternion* out, Eina_Quaternion const* > > a, Eina_Quaternion const* b ) > > eina_quaternion_transform ( Eina_Quaternion* out, Eina_Quaternion const* > > v, Eina_Matrix4 const* m ) > > I am fine with all the above eina change. > Do they need to be EAPI? Why not static inline? (I know some of them are quite big, though) > > > eina_str.h > > eina_str_base64_decode ( char const* src, int* decoded_str_len ) > > eina_str_base64_encode ( unsigned char const*
Re: [E-devel] [EGIT] [core/efl] master 01/01: eina_js: Fix documentation generation
2016-01-05 21:07 GMT-02:00 Stefan Schmidt :
> hello.
>
> On 05/01/16 17:29, Stefan Schmidt wrote:
>
>> stefan pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=2fef60b718cca3a654f29b933ffcb33888cc974e
>>
>> commit 2fef60b718cca3a654f29b933ffcb33888cc974e
>> Author: Stefan Schmidt
>> Date: Tue Jan 5 17:09:31 2016 +0100
>>
>
> Grr, my bad. The real author here was Vitor Sousa <
> vitorsousasi...@gmail.com>
> I just added the reference to the phab ticket and forgot to handle the
> --author bits when amending.
>
> Sorry Vitor for stealing your credit here. :(
>
Haha, it is OK :)
It is just a tiny commit.
Regards
Vitor Sousa.
> regards
> Stefan Schmidt
>
>> eina_js: Fix documentation generation
>> Summary:
>> Fix doxygen's documentation generation.
>> A bug in doxygen makes it fail with the
>> _libv8_property_callback_info_test
>> class.
>> We put a #ifndef EFL_DOXYGEN around it to avoid it being seen by
>> doxygen.
>> Add a NOTE comment about this.
>> ref T3005
>> @fix
>> Test Plan: make doc must succeed
>> Reviewers: felipealmeida, stefan_schmidt
>> Projects: #efl
>> Differential Revision: https://phab.enlightenment.org/D3534
>> ---
>> src/bindings/js/eina_js/eina_js_compatibility.hh | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/src/bindings/js/eina_js/eina_js_compatibility.hh
>> b/src/bindings/js/eina_js/eina_js_compatibility.hh
>> index 9ef0cb8..159c74a 100644
>> --- a/src/bindings/js/eina_js/eina_js_compatibility.hh
>> +++ b/src/bindings/js/eina_js/eina_js_compatibility.hh
>> @@ -316,13 +316,17 @@ struct _libv8_callback_info_test
>> {
>> };
>> +// NOTE: ifndef needed because a bug in doxygen makes it fail with
>> this class
>> +#ifndef EFL_DOXYGEN
>> template
>> struct _libv8_property_callback_info_test
>> : std::true_type {};
>> +#endif
>> typedef
>> v8::Handle(*_libv8_getter_callback)(v8::Local,
>> v8::AccessorInfo const&);
>> typedef void(*_libv8_setter_callback)(v8::Local,
>> v8::Local, v8::AccessorInfo const&);
>> +#ifndef EFL_DOXYGEN
>> template
>> struct _libv8_property_callback_info_test
>> > @@ -339,6 +343,7 @@ struct _libv8_property_callback_info_test
>> : std::false_type
>> {
>> };
>> +#endif
>> static constexpr bool const v8_uses_isolate =
>> _libv8_isolate_test<>::value;
>> static constexpr bool const v8_uses_callback_info =
>> _libv8_callback_info_test<>::value;
>>
>>
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Work items for 1.17
Hello. This comes up from my personal run through phab. Might be misguided, wrong or I might even had forgotten something. Speak up if this is the case. Please have a look at the following and see if you can help to fix them. Phab show stopper: -- https://phab.enlightenment.org/T3008 The alignment of popup is wrong Phab high: -- https://phab.enlightenment.org/T2042 evas_object_geometry_get called on elm_ctxpopup object always returns width and height equals to 0 https://phab.enlightenment.org/T2940 tests/eina_cxx/eina_cxx_test_ptrlist.cc does not compile on Windows https://phab.enlightenment.org/T2938 The example evas-vg-simple.c seg fault on Windows https://phab.enlightenment.org/T2835 elementary application segfaults when window type is set to ELM_WIN_SOCKET_IMAGE https://phab.enlightenment.org/T2789 evas image delete crash https://phab.enlightenment.org/T2708 Genlist tree+homogeneous broken Coverity high impact: - Our Coverity builds are still in the queue. Will update here once I have recent results. New APIs with missing test cases: - This is still a bit in flux (see the 1.17 alpha1 ABI report) and I hope to point out the missing bits after beta1 is out. If you know you are missing test cases fo you new API you should still go ahead and bring them in now! regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 03/03: widget: check next_item existence when focusing before calling widget fns
I encountered this while using keyboard navigation in the evry launcher in
Enlightenment. I believe it occurs when there is no "next" item due to
mixing elm widgets with evas/edje objects.
On Wed, Jan 6, 2016 at 11:56 PM Amitesh Singh
wrote:
> Hello Mike
>
> On Jan 7, 2016 3:40 AM, "Mike Blumenkrantz" <
> michael.blumenkra...@gmail.com>
> wrote:
> >
> > discomfitor pushed a commit to branch master.
> >
> >
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=92481addac649391cd97d73f384dfe23603a4c87
> >
> > commit 92481addac649391cd97d73f384dfe23603a4c87
> > Author: Mike Blumenkrantz
> > Date: Wed Jan 6 17:05:44 2016 -0500
> >
> > widget: check next_item existence when focusing before calling widget
> fns
> >
> > ERRlib/eo/eo.c:753 Unable to resolve op for api func
> 0x77cc17ce
> > ---
> > src/lib/elm_widget.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/lib/elm_widget.c b/src/lib/elm_widget.c
> > index f917d29..97ef045 100644
> > --- a/src/lib/elm_widget.c
> > +++ b/src/lib/elm_widget.c
> > @@ -2432,7 +2432,8 @@ _elm_widget_focus_next_get(const Eo *obj,
> Elm_Widget_Smart_Data *sd, Elm_Focus_D
> > *next_item = sd->item_focus_right;
> > else if (dir == ELM_FOCUS_LEFT)
> > *next_item = sd->item_focus_left;
> > - o = elm_object_item_widget_get(*next_item);
> > + if (*next_item)
> > + o = elm_object_item_widget_get(*next_item);
> >
> Thanks for the fix. This eo error was annoying for sometime and I noticed
> it on day before yesterday when I was implementing a feature related to
> focus.(this error comes when there is no next focusable object). Now I know
> why eo was complaining about it. I knew it is related to some logic on
> finding next object item and possibly next was null as the same error does
> not come in case of prev focusable item (e.g. alt-tab..)
> Unfortunately, I could not able to trace it as eo error was not giving much
> information. It would be super nice if you share how did you know the root
> point. This would help others in future to hunt down similar problems in
> future.
>
> > if (!o)
> > {
> >
> > --
> >
> >
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 3d, Eina matrix, Ector, etc...
On Thu, Jan 7, 2016 at 1:09 AM, Jean-Philippe André wrote:
> On 7 January 2016 at 09:59, Cedric BAIL wrote:
>> On Tue, Jan 5, 2016 at 10:04 PM, Jean-Philippe André
>> wrote:
>> > Recently a series of patches for Evas 3d and Evas VG have been merged in
>> > (mostly by Cedric and myself), and add a bunch of new APIs as well as
>> EAPI
>> > symbols.
>> >
>> > I also accepted two patches and forgot to push them yesterday before the
>> > freeze:
>> > 1. 996d17bcc5a08e75f evas: Update Ector_Color structure
>> > 2. d2bb0eefc4a2eb640 Evas 3d: Get hash table of scenes using the given
>> node
>> > as root.
>> >
>> > If you find them not acceptable for this release, please revert (patch 1.
>> > is probably fine... but see below).
>> >
>> >
>> > None of the Ector APIs are stable.
>> >
>> >
>> > So, this raises a few questions:
>> > - Should eina_vector{2,3} be static inline in the header instead of EAPI?
>> > (less symbols)
>>
>> I think so.
>>
>
> That's done (static inline, no EAPI)
> Eina_Vector3 has not been merged in EFL. I guess this will wait until 1.18?
> Or do we want them now for 1.17? (for consistency... but i don't like the
> idea of rushing this in)
>
> See https://phab.enlightenment.org/D3527
>
> (it still needs to be inlined anyway)
No need to rush that in I think,
>> > - Should we even install the Ector headers?
>>
>
> They are not installed anymore. So the next point must be fixed :)
>
>
>> > - Should Ector_Color be Efl.Gfx.Color instead? Or Eina? (I argued myself
>> > that color belonged to ector, but now I wonder, considering ector is not
>> > stable)
>>
>> I have been thinking they should belong to Efl.Gfx.Color in fact as we
>> do have API to set color in Efl.Gfx and it would make sense to make
>> this compatible with that structure. I may do that change tomorrow if
>> nobody raise their voice on the matter.
>
> Ok, I'll let you do that then. Thanks.
I will land a patch shortly for that soon.
--
Cedric BAIL
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1
On Thu, Jan 7, 2016 at 3:56 AM, Jean-Philippe André wrote: > On 7 January 2016 at 03:38, Cedric BAIL wrote: >> >> > [...] >> > Edje_Common.h >> >> edje_size_class_list ( ) >> > > I'm not a fan of this. It's just like text_class and color_class, so fine, > but I think an iterator would have been better. > Consistency is important, though. Yes, for consistency alone I agree on this API (Even if I prefer iterator). >> > edje_mmap_size_class_iterator_new ( Eina_File* f ) >> > edje_mmap_text_class_iterator_new ( Eina_File* f ) >> > edje_size_class_active_iterator_new ( ) >> > edje_text_class_active_iterator_new ( ) > > OK, so those APIs are in fact useless right now. > > They return an iterator to a private struct: Edje_Size_Class or > Edje_Text_Class. Oh, interesting I didn't notice we didn't export those structure. We do export Edje_Color_Class and I was expecting the same behavior for this two class. > A few solutions: > - Make those structs public and STABLE Any reason why not doing so ? > - Keep them opaque but add APIs to inspect them (eg. > edje_size_class_iterator_item_name_get() , > edje_size_class_iterator_item_del() ...) I don't like adding accessor that will need binding later on. > - Remove these APIs (they return a different set than the class_list > functions) This API has been useful for color class in the past, I am guessing it would be the same for this too. > Also, what about EO and bindings here? I am guessing we could expose a root singleton Edje object that this function get attached to, but the main question is would that be useful to an application ? I am not sure as this is something that elementary do act on. No obvious answer at this stage. > What do you guys think? > > All those APIs need test cases btw. True. >> > Edje_Legacy.h >> > edje_object_size_class_del ( Evas_Object* obj, char const* size_class ) >> > edje_object_text_class_del ( Evas_Object* obj, char const* text_class ) >> >> I am fine with all the above one. > > Are those necessary? Adding legacy APIs for new things. > No EO equivalent? Oh, that's a mistake it should have been an Eo API with automatically generated code for legacy. I didn't notice that. Thanks for pointing it, will fix it right away. It actually also apply to color_class_del ! >> eina_value.h >> > eina_value_optional_empty_is ( Eina_Value const* value, Eina_Bool* >> > is_empty ) >> > eina_value_optional_empty_new ( ) >> > eina_value_optional_type_get ( Eina_Value* value )> >> eina_value_optional_new ( Eina_Value_Type const* subtype, void const* >> > value ) >> > eina_value_optional_pget ( Eina_Value* value, void* subvalue ) >> > eina_value_optional_pset ( Eina_Value* value, Eina_Value_Type const* >> > subtype, void const* subvalue ) >> > eina_value_optional_reset ( Eina_Value* value ) >> > EINA_VALUE_TYPE_OPTIONAL [data] >> > > So those optional values are really just values that may be unset? > I'm not sure why a normal eina_value can't just have the empty property, > and have a void type that stores nothing. > Did I miss something? I think that Felipe can explain that better than I can. >> > eina_matrix.h >> > eina_matrix2_array_set ( Eina_Matrix2* m, double const* v ) >> > eina_matrix2_copy ( Eina_Matrix2* dst, Eina_Matrix2 const* src ) >> > eina_matrix2_identity ( Eina_Matrix2* m ) >> > eina_matrix2_inverse ( Eina_Matrix2* out, Eina_Matrix2 const* mat ) >> > eina_matrix2_multiply ( Eina_Matrix2* out, Eina_Matrix2 const* mat_a, >> > Eina_Matrix2 const* mat_b ) >> > eina_matrix2_multiply_copy ( Eina_Matrix2* out, Eina_Matrix2 const* >> > mat_a, Eina_Matrix2 const* mat_b ) >> > eina_matrix2_type_get ( Eina_Matrix2 const* m ) >> > eina_matrix2_values_get ( Eina_Matrix2 const* m, double* xx, double* xy, >> > double* yx, double* yy ) >> > eina_matrix2_values_set ( Eina_Matrix2* m, double xx, double xy, double >> > yx, double yy ) >> > eina_matrix3_array_set ( Eina_Matrix3* m, double const* v ) >> > eina_matrix3_copy ( Eina_Matrix3* dst, Eina_Matrix3 const* src ) >> > eina_matrix3_multiply ( Eina_Matrix3* out, Eina_Matrix3 const* mat_a, >> > Eina_Matrix3 const* mat_b ) >> > eina_matrix3_multiply_copy ( Eina_Matrix3* out, Eina_Matrix3 const* >> > mat_a, Eina_Matrix3 const* mat_b ) >> > eina_matrix3_position_transform_set ( Eina_Matrix3* out, double const >> > p_x, double const p_y ) >> > eina_matrix3_scale_transform_set ( Eina_Matrix3* out, double s_x, double >> > s_y ) >> > eina_matrix4_array_set ( Eina_Matrix4* m, double const* v ) >> > eina_matrix4_copy ( Eina_Matrix4* dst, Eina_Matrix4 const* src ) >> > eina_matrix4_multiply_copy ( Eina_Matrix4* out, Eina_Matrix4 const* >> > mat_a, Eina_Matrix4 const* mat_b ) >> > eina_matrix4_ortho_set ( Eina_Matrix4* m, double left, double right, >> > double bottom, double top, double dnear, double dfar ) >> > eina_normal3_matrix_get ( Eina_Matrix3* out, Eina_Matrix4 const* m ) >> > >> > eina_quaternion.h >> > eina_quaternion_angle_plains ( Eina_Quaternion* a, Eina_Quaternion* b ) >> > eina_quaternion
Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1
On Thu, Jan 7, 2016 at 7:29 PM Cedric BAIL wrote: > On Thu, Jan 7, 2016 at 3:56 AM, Jean-Philippe André > wrote: > > On 7 January 2016 at 03:38, Cedric BAIL wrote: > >> > >> > [...] > >> > Edje_Common.h > >> > >> edje_size_class_list ( ) > >> > > > > I'm not a fan of this. It's just like text_class and color_class, so > fine, > > but I think an iterator would have been better. > > Consistency is important, though. > > Yes, for consistency alone I agree on this API (Even if I prefer iterator). > > >> > edje_mmap_size_class_iterator_new ( Eina_File* f ) > >> > edje_mmap_text_class_iterator_new ( Eina_File* f ) > >> > edje_size_class_active_iterator_new ( ) > >> > edje_text_class_active_iterator_new ( ) > > > > OK, so those APIs are in fact useless right now. > > > > They return an iterator to a private struct: Edje_Size_Class or > > Edje_Text_Class. > > Oh, interesting I didn't notice we didn't export those structure. We > do export Edje_Color_Class and I was expecting the same behavior for > this two class. > > > A few solutions: > > - Make those structs public and STABLE > > Any reason why not doing so ? > > > - Keep them opaque but add APIs to inspect them (eg. > > edje_size_class_iterator_item_name_get() , > > edje_size_class_iterator_item_del() ...) > > I don't like adding accessor that will need binding later on. > > > - Remove these APIs (they return a different set than the class_list > > functions) > > This API has been useful for color class in the past, I am guessing it > would be the same for this too. > > I'll likely write a text class editor for elm at some point to complement the color class one. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
