Hello. On 08/01/16 01:27, Cedric BAIL wrote: > On Thu, Jan 7, 2016 at 3:56 AM, Jean-Philippe André <[email protected]> wrote: >> On 7 January 2016 at 03:38, Cedric BAIL <[email protected]> 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.
What is the outcome for these above APIs? >> 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 > ! I lost track on this one. Is it fixed? regards Stefan Schmidt ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
