Hi,
Just a word about panes and other new widgets: yes they got broken at some point but should be fixed now that the "EO" theme API has been merged. I think most of the existing Efl.Ui.Xxx widgets should soon become usable. But I am not ready to commit yet for all of elementary (note: the model API is still in flux and the [gen]list widget isn't here yet). @netstar proposed branching off to EFL 2 and no one responded to that (as far as I can tell). I very very much wish we had taken that route as the most painful part in this interfaces rework is to keep legacy working. Unfortunately we have reasons for not branching off, as follows: - We need the existing ecosystem for testing (E, apps, Tizen, etc...). Breaking compilation or runtime or existing apps would be a huge PITA. Having a separate .so file (libefl.so.2) would mean a lot less out-of-the-box testing. Yes, we break stuff in legacy, but this is by accident, not by design. I hope it is clear that we are still trying hard to keep things in order. - We expect the existing ecosystem to progressively adapt to the EO API, by modifying a UI component here and there, adding a new view or whatnot in the application, etc... We don't expect an immediate port of existing legacy apps to EO-only API. OTOH when it comes to bindings (Lua, C++, C# for now), everything is new, so legacy doesn't really matter. Cedric mentioned to me a couple of times how long it took large projects using Qt4 to finally move on to Qt5. So we're trying to avoid that bottleneck. I would very much like releasing at least something. Maybe the distinction between ALPHA and BETA is a good idea. (BETA for eo, eolian, ecore, and ALPHA for evas, edje, elm). efl/interfaces is a mix of both. Then we can commit to stop changing those "BETA" API's unless it's absolutely necessary (unlike a lot of the changes happening now in the interfaces). As for specific APIs we can also make use of @beta in EO. Best regards, PS: I say "EO" here as I heard about the idea of calling this API the "unified interface" (whilst I like the name, it boils down to UI and UI means user interface^^). On Mon, Dec 11, 2017 at 9:46 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sun, 10 Dec 2017 23:41:20 +0000 Andrew Williams <a...@andywilliams.me> > said: > > > Hi, > > > > I had not intended to seem like I was giving up - I am pushing hard to > try > > and have this discussion as I think it is important. The paragraph you > > referenced was intending to point out that our mailing list discussions > do > > not have an open nature to them so others feel it is not worth > > contributing. When words like “guarantee” and “zero value” are used can > you > > not see how that could be received? > > because i have seen history and those words are the truth given history > and my > experience. ok "zero value" is like "it's worth a few cups of coffee when > we're looking at buying a car". not literally zero but very very very low > value > compared to the big picture. yes. they are strong words. i feel strongly > about > this. are you saying that i am not allowed to feel strongly about this and > should tone everything down just in case you get discouraged. i have to > pretend to not feel strongly and be dishonest about my opinion? i expected > better of you. > > i KNOW who wants interfaces in things like c# and a subset is useless to > them. > they have to be able to build entire apps with the ui in that language. > it's > all of it or not bother. this applies to js, lua and python too. > > i also know that even the core is unstable and far from settled. that > means the > chances of a break are high. this means that apps cant really use any of > eo and > interfaces as the changes of "it will break" are close to 100%. somewhere, > somehow something will break - even if just 1 or 2 small things, but enough > where "i upgraded efl and app X now crashes, or doesn't start because > symbol X > not found" will be the result. it only takes one small thing to cause > that. > > lots of the core interfaces like on efl loop are not re-using shared > interfaces > yet and actually should probably be doing just that. until we implement > more of > the higher level AND then stand back and go "there's a design pattern > there. > let's unify it under a single interface everyone inherits and shares so > it's > consistent" there will be such changes. > > i think you're jumping the gun on such a release without the attendant > warnings > of "this stuff will break". i have no confidence in what you proposed to > release as stable as being solid enough to put the label on it you want - > not > now or even in a few weeks from now. perhaps in 2 or 3 months, but that's > about the same timeline for getting all of the "target api set" up through > ui > done too as much is being done in parallel. then we'd need ~1 month for a > release cycle at least. probably longer if we want to expose all these new > eo > based things as "stable beta". > > it's far more important to get the core lower levels right as everything is > built on top, than to get leaf nodes in the class tree right... thus why > they > would require more conservative attention. > > > As I have pointed out before the interface parent ticket has new tickets > > added faster than we are closing existing ones. I see also that > completely > > broken eo widgets are being pushed into master (see efl.ui.panes for > > example) and abandoned. With that in mind can we realistically expect to > > release the whole lot in one go this decade? > > it has to. it actually has to be done in the next few months. like ~2-3. > not a > subset. everything including the ui classes. yes. stuff is there that is > broken. the panes actually did work. last i knew they worked, then ANOTHER > change somewhere else in evas broke them, ami fixed them, now they > re-broke and > he didn't know. they were not pushed AS broken widgets... > > > I will work with the folk I have been chatting with to see if I can pull > > together the requirements that are driving the desire to start building > on > > eo api rather than legacy. > > without them chiming in and saying why they want a small subset released > and > what they at all intend to build with it... i am sticking to my position on > this - that it's dangerous to mark as stable (beta stable as you say). > dangerous for the work being done, dangerous to extending timelines for the > work as a whole, dangerous to people then using those api's as given the > past > it is a nigh guarantee that those api's will have to break. a lot changed > and > broke AS interfaces were worked on and we realized we need to do something > in a > certain way or need a feature or need to redesign something etc. ... so > until > those higher level changes have settled down at least to small things like > arguing over a property, method or event name... i wouldn't say eo is > releasable. futures still are not a done thing and they are central to eo's > core. without them being actually used first by people able to stomach a > break > and redesign if it has to happen... chasing a "let's release as stable beta > some subset of core" is a bit of a pipe dream. > > > Andrew > > On Sun, 10 Dec 2017 at 11:33, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > > > On Sun, 10 Dec 2017 09:35:05 +0000 Andrew Williams < > a...@andywilliams.me> > > > said: > > > > > > > Hi, > > > > > > > > Apologies I was not aware of these plans that everyone agreed on. > Can you > > > > please point me to this plan? It is very difficult to make a case for > > > > change without knowing the preceding plan that would need to change. > > > > > > that all of eo/efl interfaces is behind the same beta flag until done. > > > it's the > > > state you see now. there were and are no plans to pick and choose some > > > interfaces to release as stable, and some not. at one point we were > talking > > > about making just eo stable but then we realized it needed lots of > changes > > > and > > > this has never come up again. > > > > > > you want the plan? see the tickets for interfaces. that's the work to > be > > > done > > > and the work done on the interfaces themselves feeds back to the lower > > > levels > > > all the time. > > > > > > > To require irc logs or ML emails asking for this change is to imply > that > > > > we, the community, are serving just this community - I thought we > were > > > > looking bigger picture than that. It would be a violation of trust to > > > paste > > > > private conversations or concerns into this email chain, perhaps > those > > > who > > > > are in agreement will contribute to this conversation. > > > > > > if you're using them as a justification, then they should be quoted > here. > > > > > > > I am confused about what you mean regarding consensus. I have seen no > > > > discussion bar this about release plans or indeed the plan / > priority for > > > > interfaces. If we could publicly discuss or collaborate on that this > > > would > > > > be a lot easier. I agree that there has been little discussion on > this > > > > > > that's because it is one blob of work and the "let's release different > b > > > its at > > > different times" is not there because that was not agreed on, otherwise > > > it'd be > > > in tickets. > > > > > > what was agreed on is what is already there in code and tickets. the > > > things to > > > be eoified (well it is a rough list that gets more refined as time goes > > > on). > > > it's all behind the same ifdef. ... > > > > > > if you want to change this direction and state... you should convince > many > > > people it's a good idea. i, so far, am not convinced it is. you'd need > to > > > convince more than me too. > > > > > > > thread but from your first email it seemed like it would be a waste > of > > > time > > > > discussing so I’m not surprised. This does not detract from the > number of > > > > people who have spoken to me that are disappointed we cannot be > thinking > > > > about releasing some of our work. > > > > > > every time i disagree you seem to take it as a "i give up". so what > should > > > i > > > do" just shut up and pretend to agree? what is the point of a > discussion > > > when > > > it has to become a "let me just lie and not express what i think to > make > > > someone else happy"? you expressed an opinion. i expressed a counter > one. i > > > believe the value does not justify the cost. i made that clear. > convince me > > > otherwise. otherwise this is not a discussion. > > > > > > > However if the plan you described is publicly available then I > apologise > > > > for the confusion. I can point these individuals to the document and > we > > > can > > > > think harder about what the smallest change could be that provides a > > > > solution for everyone. > > > > > > > > Thanks, > > > > Andrew > > > > On Sun, 10 Dec 2017 at 01:09, Carsten Haitzler <ras...@rasterman.com > > > > > wrote: > > > > > > > > > On Sat, 09 Dec 2017 13:38:51 +0000 Andrew Williams < > > > a...@andywilliams.me> > > > > > said: > > > > > > > > > > > This has become a circular argument, as many do around here, vis: > > > > > > *) people are asking for us to try and agree on stable areas of > the > > > API > > > > > so > > > > > > we can start testing it externally > > > > > > *) we won’t do that until there is proof that people are using > our > > > beta > > > > > > APIs (which are currently unstable). > > > > > > How can we break this loop? > > > > > > > > > > which people where are asking for a release of a small susbet of > the > > > api? > > > > > show > > > > > me. > > > > > > > > > > > I cannot believe that all of the new APIs are completely unstable > > > until > > > > > we > > > > > > release - that is basically a house of cards that we hope one day > > > will > > > > > > become rigid. Some of what we have is more mature than other > things > > > - but > > > > > > every single API we add immediately goes into the BETA flag for > next > > > > > > release.. > > > > > > > > > > you are asking for a change of plans that everyone working on > > > eo/interfaces > > > > > agreed on. you have to make your case for that CHANGE. don't tell > me > > > > > "people > > > > > are asking". show me the emails here asking, and from who. show me > the > > > irc > > > > > logs or the phab tickets. i'm not talking about the full release of > > > what > > > > > was > > > > > planned but the subset you mentioned. see above. those changes come > > > with a > > > > > cost > > > > > (locking yourself in). we'd be stupid to pay the cost with no > evidence > > > > > beyond > > > > > your comment "people are asking". not to mention it'd also be > ignoring > > > the > > > > > previous agreement on what to do. > > > > > > > > > > until the people working on eo/interfaces can ALL come to a > > > consensus... > > > > > nothing is going to change. and there is no input from most of > them at > > > this > > > > > point, and no overwhelming evidence to ignore any input from them > if it > > > > > were to > > > > > come. > > > > > > > > > > > If we cannot make any release in the way previously discussed > then we > > > > > > absolutely should have some other way of illustrating our > confidence > > > in > > > > > an > > > > > > API. Therefore an alternative I propose is to add an ALPHA flag > > > (which is > > > > > > mostly what BETA feels like at the moment) where new Eo goes and > > > those > > > > > > marked as BETA are the classes we feel could be eliciting > feedback. > > > > > > This way we are able to show where we know we have not tested as > > > much and > > > > > > can show a journey through creation, testing and integration > into the > > > > > BETA > > > > > > area. > > > > > > > > > > > > Without this we are just hoping that some day all our classes > will be > > > > > > stable so we can roll a release... > > > > > > > > > > > > Andrew > > > > > > On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler < > ras...@rasterman.com> > > > > > wrote: > > > > > > > > > > > > > On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail <ced...@ddlm.me > > > > > said: > > > > > > > > > > > > > > > > -------- Original Message -------- > > > > > > > > > Subject: Re: [E-devel] What are we going to release? > > > > > > > > > Local Time: December 7, 2017 5:06 PM > > > > > > > > > UTC Time: December 8, 2017 1:06 AM > > > > > > > > > From: ras...@rasterman.com > > > > > > > > > To: Andrew Williams <a...@andywilliams.me> > > > > > > > > > Enlightenment developer list < > > > > > > > enlightenment-devel@lists.sourceforge.net> > > > > > > > > > > > > > > > > > > On Thu, 07 Dec 2017 13:45:51 +0000 Andrew Williams > > > > > > > a...@andywilliams.me > > > > > > > > > said: > > > > > > > > > > > > > > > > > > Without a guarantee of no changes then you don't provide > > > anything > > > > > > > stable to > > > > > > > > > build on top of. It's no different to what we do now. We > could > > > just > > > > > > > say "we > > > > > > > > > think these interfaces are ok now - you can try using them > but > > > we > > > > > might > > > > > > > > > still break them" which is is not some special beta > release. > > > it's > > > > > just > > > > > > > > > providing a "we think its more stable now" assessment. > > > > > > > > > > > > > > > > I am thinking of a stronger commitment on our part here. > > > Basically > > > > > as I > > > > > > > said > > > > > > > > in my email above, if a binding doesn't report a real big > problem > > > > > with > > > > > > > what > > > > > > > > is under that RC umbrella, then we do not break it. > > > > > > > > > > > > > > unless it's "absolutely will not break at all" then it's > really no > > > > > better > > > > > > > in > > > > > > > the end. > > > > > > > > > > > > > > > I am afraid that for a lot of this lower level, we are now > > > starting > > > > > to do > > > > > > > > what we were doing before we release EFL 1.0. Trying to make > it > > > > > perfect > > > > > > > > without having ever spend the time to prepare a proper > release. > > > We > > > > > need > > > > > > > to > > > > > > > > focus and get things out. > > > > > > > > > > > > > > > > > but still if it's just what you were saying then what apps > can > > > be > > > > > > > written > > > > > > > > > using those api's - and will they be? > > > > > > > > > > > > > > > > EFL apps already exist. They can get migrated to the new API. > > > That > > > > > is the > > > > > > > > main target of this release. > > > > > > > > > > > > > > other than some mechanical "sed work" like > > > s/evas_object_del/efl_del/g > > > > > ... > > > > > > > which buys nothing really useful... what is really going to be > > > done? > > > > > and > > > > > > > what > > > > > > > will this demonstrate to us or anyone else api-wise? not much. > > > > > > > > > > > > > > > >> Why does it have to be black and white? releasing does not > > > > > "guarantee > > > > > > > no > > > > > > > > >> changes", it probably does need to guarantee backward > > > > > compatibility. > > > > > > > The > > > > > > > > >> challenge I see with our current situation is that we have > > > > > published > > > > > > > "beta" > > > > > > > > >> which is not even close to stable and now don't have a > clear > > > next > > > > > > > step to > > > > > > > > >> get people involved. A "release candidate" might be an > obvious > > > > > step > > > > > > > which > > > > > > > > >> comes as part of a release plan, which is what I wanted to > > > > > discuss. > > > > > > > > >> > > > > > > > > >> what we have is a release candidate so to speak that is > > > clearly > > > > > > > showing its > > > > > > > > >> state - it's not stable. > > > > > > > > >> > > > > > > > > >> trying to release something as stable that is NOT (call > it a > > > > > release > > > > > > > > >> candidate or whatever) is just being dishonest. > > > > > > > > >> > > > > > > > > >> I think that EFL and our community is in a different > place to > > > > > where > > > > > > > it was > > > > > > > > >> years before ecore. We should learn from (everyone's) > > > experience > > > > > and > > > > > > > figure > > > > > > > > >> how to apply that to our current situation. Our current > > > reality is > > > > > > > that > > > > > > > > >> companies with real products want to build on what we > have. > > > That's > > > > > > > pretty > > > > > > > > >> exciting I reckon. > > > > > > > > >> > > > > > > > > >> and they need the full stack done to build them. not just > some > > > > > small > > > > > > > > >> sub-bits. thus i point out what i did already... what apps > > > with > > > > > such a > > > > > > > > >> subset of api's (efl core/loop/net?). they can't even > build > > > things > > > > > > > with > > > > > > > > >> efl.gfx. they need efl.ui and even then the efl.ui we are > > > > > proposing > > > > > > > means > > > > > > > > >> them losing several widgets they have used before etc. > ... so > > > > > that's > > > > > > > > >> already a sacrifice. > > > > > > > > > > > > > > > > No, they don't ! Do not forget that EFL Eo API is compatible > > > with the > > > > > > > legacy > > > > > > > > API and that this is especially done to allow people to > migrate > > > their > > > > > > > > application as time goes. Bits by bits. > > > > > > > > > > > > > > they absolutely do. e.g. c#. without the full stack it's > > > pointless. and > > > > > > > they're > > > > > > > not going to migrate... except rewrite in a new language. you > know > > > > > that as > > > > > > > well > > > > > > > as i do. > > > > > > > > > > > > > > > [snip] > > > > > > > > > > > > > > > > >> Should we instead figure when we might start releasing and > > > set an > > > > > > > > >> expectation to the public? Something like "come back in > 2019"? > > > > > > > > >> > > > > > > > > >> well we hoped to finish in 2016, then by end of 2017 ... > we > > > have a > > > > > > > better > > > > > > > > >> chance now as people are really focusing on it, but i > actually > > > > > suspect > > > > > > > > >> 2019 is a safe bet. mid 2018 might be "optimistic" and > end of > > > Q1 > > > > > 2018 > > > > > > > is > > > > > > > > >> "totally crazy optimistic if the world all aligns right". > > > > > > > > > > > > > > > > If we keep trying to release everything at once without > > > commitment > > > > > and > > > > > > > not by > > > > > > > > slice of useful bits, then sure we will still be at it in > 2019 or > > > > > maybe > > > > > > > even > > > > > > > > later. But we don't need to do so. Existing apps and existing > > > > > bindings > > > > > > > won't > > > > > > > > stop working. The new API is designed to allow for a smooth > > > > > transition. > > > > > > > It is > > > > > > > > designed to allow you to mix old and new together. This way, > you > > > can > > > > > > > already > > > > > > > > build a useful application by building with Efl_Core, > Efl_Net and > > > > > > > Elementary. > > > > > > > > This is fine. > > > > > > > > > > > > > > it's not about "trying to release all at once". it's about not > > > painting > > > > > > > ourselves into a corner. not limiting ourselves before we > really > > > need > > > > > to. > > > > > > > > > > > > > > every release we do means we stop doing eo work and instead > > > stabilize a > > > > > > > release. the more we do the more we push a final result into > 2019. > > > > > without > > > > > > > a > > > > > > > significant amount of the interfaces api available you won't > > > really get > > > > > > > much, if > > > > > > > any, valuable feedback, and instead simply lose at least a few > > > months > > > > > of > > > > > > > work > > > > > > > time into release work. (1 month per release at least). > > > > > > > > > > > > > > i don't see how this gets us to our goal better or sooner than > > > what we > > > > > are > > > > > > > doing now. what i do see is: > > > > > > > > > > > > > > 1. getting there later > > > > > > > 2. not gaining anything really valuable in return for that > delay > > > > > > > > > > > > > > but here's my take... the above is my advice, but delay-wise... > > > i'm not > > > > > > > responsible. but mark my words that the goal that MATTERS - > > > interfaces > > > > > > > that can > > > > > > > be used in BINDINGS like C#, C++, JS, LUA etc. will only get > > > delayed > > > > > ... > > > > > > > and > > > > > > > you know well enough how much a release delays. we have a whole > > > > > mountain of > > > > > > > new coverity complaints. any eo api to be "stabilized for > release" > > > > > needs a > > > > > > > lot > > > > > > > of attention in review and actual use before that release goes > out > > > if > > > > > you > > > > > > > want > > > > > > > any kind of stability guarantee to it. and you know full well > that > > > just > > > > > > > these > > > > > > > few api's are of nil use to the consumers of bindings like > above > > > until > > > > > > > there > > > > > > > is a LOT more there. > > > > > > > > > > > > > > but if you wish to take the risk and the blame when things get > > > > > delayed... > > > > > > > you > > > > > > > go ahead. all i want is proof of actual use in the wild like > you > > > claim, > > > > > > > because unless there is such proof, no lessons will ever be > learned > > > > > from > > > > > > > this. > > > > > > > think of it as a "KPI". proof that the "stable beta api" is > used > > > > > without > > > > > > > the > > > > > > > current unstable beta #define and so on... in more than a few > > > trivial > > > > > > > places. > > > > > > > > > > > > > > > Cedric > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > ------------------ > > > > > > > > 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 > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > ------------------ > > > > > > > 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 > > > > > > > enlightenment-devel@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment- > devel > > > > > > > > > > > > > -- > > > > > > http://andywilliams.me > > > > > > http://ajwillia.ms > > > > > > > > > > > > > > ------------------------------------------------------------ > ------------------ > > > > > > 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 > > > > > > 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 > > > > > > > > > > -- > > > > http://andywilliams.me > > > > http://ajwillia.ms > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > Carsten Haitzler - ras...@rasterman.com > > > > > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > ------------------------------------------------------------ > ------------------ > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
