On Mon, 8 Jan 2018 15:40:02 +0900 Jean-Philippe André <[email protected]> said:
> 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? it's not used... so i'd say drop it. this probably will end up part of the efl.task class or the efl.exe class ... :) > > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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
