Hello, This topic is a very important one and will decide the future look of our API. It does involve also our bindings and not only the C API. For people who don't know yet, we are rolling in currently a new API using Eo. This is currently marked as beta, but we are targetting to release it along with 1.14. So very soon in term of development. This new API being parallel to the current one enable us to fix some of our naming mistake to make it easier for beginner to understand and use our API. Also if it can be made future proof that's another benefit.
So here is the question : Do you think we should put our class into a specific namespace or make things flat and directly in the top level efl namespace ? To give an example we are talking about something like (with namespace vs no namespace) : efl_gfx_color_set vs efl_color_set efl_gfx_path_dup vs efl_path_dup Think that all our object are turning into Eo object (Ecore_Timer, Ecore_Con, Eio, ...). I think there is a middle ground that can be done by actually generating a separated header that is not automatically included per namespace. So you would : #include <Efl_Gfx.h> And you would then have efl_color_set, efl_path_dup and so on. So what is your opinion guys ? You can vote there https://phab.enlightenment.org/V11, but please share your comment on it here. That will be easier to discuss further. Also I don't want to have this running for long, so hurry to get involved ! -- Cedric BAIL ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
