On Thu, Jan 7, 2016 at 7:29 PM Cedric BAIL <[email protected]> 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. > > I'll likely write a text class editor for elm at some point to complement the color class one. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
