More renaming ahead? :) I'll assume we might keep an "eo_prefix" for some APIs like "efl_part" or "efl_file" to not become too long in C (important: this affects only C!).
On Sat, Dec 23, 2017 at 3:16 AM, Andrew Williams <[email protected]> wrote: > Hi all, > > I recently updated the API landing page to group by namespace: > https://www.enlightenment.org/develop/api/start > > What this has indicated is that there are a few things out of place. The > list as far as I can see it is: > > Efl.Access.* -> Efl.Ui.Access > Nope! That was also my reaction at first, though :) Access can be used in a non-UI environment, conceptually. Ask @stanluk for more details, but he managed to convince me. > Efl.Animator -> Efl.Animation.Animator > @cedric? > Efl.File -> Efl.Io.File > This name makes sense But I already see an Efl.Io.File class? Gustavo, any input here? Efl.Io refers to actual I/O (open, read, write, close...) while Efl.File is just for the (image/edje) file set/get. > Efl.Flipable -> Efl.Image.Flipable > Yes. > Efl.Observer -> Efl.Observable.Observer > Makes sense (though it mixes class name and namespace which some people dislike). > Efl.Pack -> Efl.Ui.Pack > Makes sense. > Efl.Part -> Efl.Layout.Part > It's not only for layout. Widget also implements the part API, so more like Efl.Ui.Part. The concept isn't necessarily limited to UI, even though all use cases are UI-related for now. > Efl.Vg -> Efl.Gfx.Vector > Sounds good. > Also I am unsure about how we can tidy these one to a better group, do they > belong in new namespaces or at the top level (i.e. along with Efl.Object): > > Efl.Container Efl.Content > Container and Content can be in Efl.Ui. > Efl.Control > raster? Do we even need this? > Efl.Duplicate > It's a very generic thing, but only implemented in a few classes. A bit like Cloneable in Java (found in java.lang). > Efl.Orientation > Could be in Gfx if needed. > Efl.Player > Efl.Screen > No idea either :) > I'd like to be able to tidy the API so we have at least 50% fewer child > namespaces to Efl. Somewhere between the number of legacy modules and the > number of namespaces currently. Yes, this makes sense to me. -- Jean-Philippe André ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
