This is an idea of what I had in mind: https://www.enlightenment.org/playground/choose-your-api.md
Xavi On Mon, 1 Apr 2019 at 17:39, Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > I agree with the point that newcomers will have no idea what EO is (and > they should not need to know). It's best to have naming targeted at the > newcomer demographic since any developers which are already invested in the > community will inherently know which API is being referred to regardless of > what we name it. > > On Mon, Apr 1, 2019 at 10:34 AM Xavi Artigas <xavierarti...@gmail.com> > wrote: > > > 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 > > > > _______________________________________________ > 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
