On Tue, 2 Apr 2019 09:37:33 -0400 Mike Blumenkrantz <michael.blumenkra...@gmail.com> 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 <ras...@rasterman.com> > wrote: > > > On Mon, 1 Apr 2019 13:59:00 -0400 Michael Blumenkrantz > > <michael.blumenkra...@gmail.com> 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 <xavierarti...@gmail.com> 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. > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > > 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 > > > > -- ------------- 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
