The problem I see with EO is that newcomers don't know what it is, so it needs to be introduced. But then again, we could do something similar: *Components (Classic)* vs *Unified (EO)*. I have been envisioning for a while a first page on the Developers section, clearly split in two, saying: CHOOSE YOUR POISON And a paragraph explaining each of the two options.
On Mon, 1 Apr 2019 at 16:12, Carsten Haitzler <ras...@rasterman.com> wrote: > On Mon, 1 Apr 2019 15:31:46 +0200 Xavi Artigas <xavierarti...@gmail.com> > said: > > > Thank you all for your feedback! > > > > My comments: > > Universal works too, but I think Unified is more specific as to its > purpose. > > I wasn't sure about the Classic name so I welcome alternatives. I like > > Components because it clearly states its problem. However, we would need > to > > explain that "the API that you have been using so far is now called > > Components API", whereas you don't need to do that if you call it > > "Classic". How about "Components (Classic) API", or "Classic (Components) > > API"? > > Synonyms for Components: Split, Detached, Separated. > > Aaaaaaaand I don't like Best and Worst because we can do better than the > > new API and I fear we can do worse than the legacy API :) > > We gave been calling them LEGACY and EO API. Legacy isn't going away any > time > soon at all. It'll require a lot of things be ported over first, and in > fact Eo > API will need to get a lot of expansion and improvements to even make that > possible, so it's going to take a long time. Given that this will be > around for > a long time, probably something like CLASSIC vs. EO will do. EO API is > pretty > exact on the dot as to what it's based on. CLASSIC is what has classically > been > around for a long time... and likely will be for a while. > > > Xavi > > > > On Mon, 1 Apr 2019 at 14:15, Mike Blumenkrantz < > > michael.blumenkra...@gmail.com> wrote: > > > > > I'd prefer "component" and "unified". They say the classics never go > out of > > > style, but they do. > > > > > > On Mon, Apr 1, 2019 at 5:32 AM Xavi Artigas <xavierarti...@gmail.com> > > > wrote: > > > > > > > Hello everybody, > > > > > > > > TL;DR: Current docs are a mess because of inconsistent naming of the > two > > > > APIs (old and new). I propose we call them Classic and Unified and > revamp > > > > the docs site. > > > > > > > > As you know, we have all been laboring in the past years to produce > a new > > > > API for EFL that presents a unified look (instead of a collection of > > > > libraries), and which is described through a high-level language > (Eolian) > > > > so it is straightforward to write bindings for languages other than C > > > > (instead of having to write and maintain manual bindings). > > > > > > > > This new API is now mature enough that parts of it have been declared > > > > stable and will be shipped in this release (1.22) without BETA > markers. > > > > This means apps can be written using this API without requesting any > > > > special BETA access, and they have a certain degree of confidence > that > > > they > > > > will continue working in future versions of EFL without change. > Actually, > > > > only the Window class has been stabilized, so no great apps will > come out > > > > of it, but we're getting there. > > > > > > > > Unfortunately, we never agreed to any name for this new API (that I > am > > > > aware of), which makes things hard to document: > > > > - The old API is being called Legacy API, but that's confusing > because > > > it's > > > > the ONLY API apps can currently use. > > > > - The new API has been called Interfaces API, but that is confusing > > > because > > > > "interface" is a programming term, and they are present in both APIs. > > > > - Beta API is also a bad name, because parts of the old API are still > > > beta, > > > > and parts of the new API are not beta anymore. > > > > - And obviously "old" and "new" are extremely non-future-proof names > for > > > an > > > > API. What are we going to call the new one? (say "newer", I dare > you). > > > > > > > > THEREFORE, I propose we start calling the old API "*Classic API*" > and the > > > > new one "*Unified API*". > > > > The Unified API presents a unified look of the library, and contains > all > > > > EFL symbol starting with efl_ or eina_. > > > > Conversely, the Classic API is a collection of libraries which have > grown > > > > organically over the years (hence "Classic") and contains the rest of > > > > symbols (evas_, ecore_, edje_, ...) > > > > This naming will only affect documentation (website, tutorials, > reference > > > > guide). No changes in code. > > > > It might not seem like a big deal, but the current state of our docs > is > > > > pretty confusing, and having things properly named and introduced > will > > > help > > > > newcomers a lot. And we do want newcomers, right? > > > > > > > > So please share your thoughts about the Classic and Unified names, > make > > > > other proposals if you wish, and I'll start revamping the docs site. > > > > > > > > Xavi > > > > > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > _______________________________________________ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
