2016-06-25 15:54 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > On Sat, 25 Jun 2016 09:08:33 -0300 Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> said: > > > On Fri, Jun 24, 2016 at 7:59 PM, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > On Fri, 24 Jun 2016 07:58:44 -0500 Stephen Houston < > smhousto...@gmail.com> > > > said: > > > > > >> I would like to add that the theme bugs on Genlist need fixing also. > Two > > >> Phab tickets in particular. 1) There is a clipping bug where, a > Genlist > > >> large enough to scroll, scrolls out of it's bounds and covers other > widget. > > >> The out of bounds content is invisible of course so you don't see it, > but > > >> you can still click into it. 2) Genlist tree, the row alternating > colors > > >> becomes messed up if a tree items children are created upon expand. > > > > > > 1) that's not a theme bug. it's an evas clipping/ object bug of some > sort. > > > 2) also not a theme bug but code bug. it just somehow doesnt re-init > items > > > with the correct edje group for odd/even. > > > > > >> Both of these bugs have Phab tickets. The eio monitor has a Phab > ticket as > > >> well and Cedric is addressing it for the release I believe. > > >> On Jun 23, 2016 7:35 AM, "Stefan Schmidt" <ste...@osg.samsung.com> > wrote: > > > > > > we have deeper problems. promises. > > > > > > right now i'm tempted to just call it quits on promises. remove them. > do > > > that stuff with events on objects. i'm tired of the disconnect on > promises > > > so drop them entirely. my patience is running thin. > > > > Just know we will be either killing the Node.JS bindings or requiring > > manual code. > > > > People will not want to use a binding that will be written like this: > > > > download = new efl.net.url_download('http:// ... '); > > download.on('result', function () { .. }); > > download.on('error', function () { ... }); > > download.on('progress', function () { ... }); > > download.work(); // the async operation > > > > This is horrible, people will expect that to work like this: > > unless we agree on promises ... yes. they will have to go and we'll have > the > above. i will not accept any implementation or solution that makes the c > api > harder to use than it needs to be. first and foremost. SECOND it then has > to > translate to other languages. >
Yeah, I totally agree on the SECOND point! With promise syntax seems you are trying to force other laguages (C, python, etc) to match a syntax that is JS only, making all the other uglyer. In python for example there are no promise concept at all, forcing python developer to use a .then method don't make ANY SENSE in a pythonic syntax. > > since you want to do promise bindings manually, then map it however you > like > manually with whatever wrapping etc. but this should not cause the api and > usage in c to be harder than it needs to be. > > > efl.net.url_download('http:// ...').then > > ( > > function (file) // success > > { > > return x; > > }, > > function (e) // error > > { > > }, > > function (p) // progress > > { > > } > > ).then( function (x) { ... }); > > > > This is what we have been advocating since the beginning, and we don't > > need a huge super Eolian class to have that in all bindings, we just > > need well defined semantics of asynchronous operations. We can > > work with Eolian/Eo Promise for that as well and that's all _I_ ask so I > > can sell EFL idea for other communities as well. > > However, you wanted to have a super uber promise first and now > > you just want to drop everything that even remotely allows us > > the second syntax. > > eh? i want nothing of the sort. there is no reason to make promises as > complex > as proposed in c. > > > I have to ask, do we even care about bindings or not? > > i care, but if we are going to disagree on promises in core efl for much > longer, then we just have to drop them. yes. people will have to do the > "obj.on > ()" stuff. it works. it's better than marching on with promises given the > extreme disagreements on them and their implementation, api and behaviour. > js > didn't have promises for many many many years. we will have to march on > without > them if we can't agree on them in the core of efl. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel