Re: [E-devel] Official name for the new API
On Tue, 2 Apr 2019 09:37:33 -0400 Mike Blumenkrantz said: > The page background loaded and the page content remained blank for a long > time before eventually loading. Seems a bit better today but still the same > issue. hmmm. ok. i was wondering if it's the kiwi-irc stuff that basically adds slowness in load due to it being a bit of foreign js and content and i've noticed page loads wait on kiwi-irc to respond where our server has already served everything except this content. at least i've noticed the content is loaded and visible but its still busy loading with nothing else appearing and it seems to be kiwi-irc servers being slow. just wondering if it's that in this case. > On Mon, Apr 1, 2019 at 7:41 PM Carsten Haitzler > wrote: > > > On Mon, 1 Apr 2019 13:59:00 -0400 Michael Blumenkrantz > > said: > > > > > Seems reasonable. Is that page intended to load in under 15 minutes or > > are we > > > having server issues again? > > > > Do you see the content in full but then still have the busy spinner going > > for a > > while with no visible updates until this spinner stops? > > > > > On Mon, 1 Apr 2019 19:55:13 +0200 > > > Xavi Artigas wrote: > > > > > > > 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. > > > > > > > > Aaaand 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: > > > > > > >
Re: [E-devel] Official name for the new API
Works for me, and I have cleared all browser caches. Weird. Here's an archived version, for your reading pleasure: https://web.archive.org/web/20190402142721/https://www.enlightenment.org/playground/choose-your-api.md Xavi On Tue, 2 Apr 2019 at 15:37, Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > The page background loaded and the page content remained blank for a long > time before eventually loading. Seems a bit better today but still the same > issue. > > On Mon, Apr 1, 2019 at 7:41 PM Carsten Haitzler > wrote: > >> On Mon, 1 Apr 2019 13:59:00 -0400 Michael Blumenkrantz >> said: >> >> > Seems reasonable. Is that page intended to load in under 15 minutes or >> are we >> > having server issues again? >> >> Do you see the content in full but then still have the busy spinner going >> for a >> while with no visible updates until this spinner stops? >> >> > On Mon, 1 Apr 2019 19:55:13 +0200 >> > Xavi Artigas wrote: >> > >> > > 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. >> > > > > > > Aaaand 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 >> > >
Re: [E-devel] Official name for the new API
The page background loaded and the page content remained blank for a long time before eventually loading. Seems a bit better today but still the same issue. On Mon, Apr 1, 2019 at 7:41 PM Carsten Haitzler wrote: > On Mon, 1 Apr 2019 13:59:00 -0400 Michael Blumenkrantz > said: > > > Seems reasonable. Is that page intended to load in under 15 minutes or > are we > > having server issues again? > > Do you see the content in full but then still have the busy spinner going > for a > while with no visible updates until this spinner stops? > > > On Mon, 1 Apr 2019 19:55:13 +0200 > > Xavi Artigas wrote: > > > > > 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. > > > > > > > Aaaand 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 langu
Re: [E-devel] Official name for the new API
On Mon, 1 Apr 2019 13:59:00 -0400 Michael Blumenkrantz said: > Seems reasonable. Is that page intended to load in under 15 minutes or are we > having server issues again? Do you see the content in full but then still have the busy spinner going for a while with no visible updates until this spinner stops? > On Mon, 1 Apr 2019 19:55:13 +0200 > Xavi Artigas wrote: > > > 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 > > > 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 > > > > 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. > > > > > > Aaaand 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 > > > > > >
Re: [E-devel] Official name for the new API
Seems reasonable. Is that page intended to load in under 15 minutes or are we having server issues again? On Mon, 1 Apr 2019 19:55:13 +0200 Xavi Artigas wrote: > 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 > > 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 > > > 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. > > > > > Aaaand 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:
Re: [E-devel] Official name for the new API
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 > 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 > > 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. > > > > Aaaand 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 > > na
Re: [E-devel] Official name for the new API
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 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 > wrote: > > > On Mon, 1 Apr 2019 15:31:46 +0200 Xavi Artigas > > 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. > > > Aaaand 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 > > > > > 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
Re: [E-devel] Official name for the new API
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 wrote: > On Mon, 1 Apr 2019 15:31:46 +0200 Xavi Artigas > 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. > > Aaaand 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 > > > 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 > >
Re: [E-devel] Official name for the new API
create a poll : https://framadate.org/create_poll.php?type=autre Vincent On Mon, Apr 1, 2019 at 3:58 PM Mike Blumenkrantz wrote: > > Component (Classic) seems acceptable, though I think there is still room > for people to not understand what is meant by this term. > > On Mon, Apr 1, 2019 at 9:32 AM Xavi Artigas wrote: > > > 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. > > Aaaand 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 :) > > > > 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 > > > 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 > > > > __
Re: [E-devel] Official name for the new API
On Mon, 1 Apr 2019 15:31:46 +0200 Xavi Artigas 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. > Aaaand 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 > > 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 > -- ---
Re: [E-devel] Official name for the new API
Component (Classic) seems acceptable, though I think there is still room for people to not understand what is meant by this term. On Mon, Apr 1, 2019 at 9:32 AM Xavi Artigas wrote: > 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. > Aaaand 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 :) > > 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 > > 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 > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Official name for the new API
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. Aaaand 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 :) 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 > 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
Re: [E-devel] Official name for the new API
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 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
Re: [E-devel] Official name for the new API
On 01/04/2019 22:39, Hermet Park wrote: Sounds good to me. Agree on this idea. Maybe universal API could be one another option... I think calling the old API the "Worst" api and the new API the "Best" API is probably the best way forward. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Official name for the new API
Sounds good to me. Agree on this idea. Maybe universal API could be one another option... On Mon, Apr 1, 2019 at 6:32 PM Xavi Artigas 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 > -- Regards, Hermet ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
