> slight problem is that in the process of ensuring edje does > its job, the over-engineering made it look like something different, and that > is where suddenly it looks bad because people use it as "something different" > then find all the creaky edge cases.
Can you tell me which "creaky edge cases" ? I never found edge bad designed or anything wrong at all on it, im talking of course about the edge that I met a good number of years ago but i assume that we still having the same one, just more improved :) For what something different people wanted to use it ? > bob is accepting that reality and trying to make something closer to what > people have expected edje to be. And what expects people edje to be ? 2013/12/16 Carsten Haitzler <ras...@rasterman.com> > On Sun, 15 Dec 2013 17:48:37 +0100 dumblob <dumb...@gmail.com> said: > > bob would not be bob if it was not tied to a single specific language. lua > (via > luajit) is at least the target we think is best. basically instead of > implementing stuff with edc to design ui elements, you use lua to do the > same. > lua is a data file. it is what implements the abstraction. the idea is > that bob > COMES with a small mountain of pre-made lua "bobjects" that already work > (and > build on top of each-other via inheritance or other mechanisms). > > the other side of bob is a c library with c apis. just like efl is today. > no > different. you expose state/data to bob from the c side (and bob can expose > data/state back to you). bob (the c library) handles the infra for this - > threading infra too, mainloop integration, sandboxing etc. etc. > > bob is fundamentally no different to edje in the very high level design. > the > difference is what is under the covers. how state is held/handled. how > state/data is exchanged/shared, how data is implemented (edc + embryo lua > atm > and bob would just be plain luajit with the above infra). bob is a result > of > lessons learned from edje over the years. > > edje was designed as nothing more than a "smart png with layers". eg a psd > or > xcf file really. a png that can resize intelligently (not just stretch) as > well > as throw in some simple states of that image (normal, activated, disabled) > and > some transitions. that was edje's design goal and intent. > > of course it was over-engineered for the job to ensure it covers that job > as > fully as it can. slight problem is that in the process of ensuring edje > does > its job, the over-engineering made it look like something different, and > that > is where suddenly it looks bad because people use it as "something > different" > then find all the creaky edge cases. > > bob is accepting that reality and trying to make something closer to what > people have expected edje to be. > > > Hi, > > > > I've recently come across https://phab.enlightenment.org/w/bob/ and I > > wonder if BÖB is going to be usable in other programming languages than > Lua > > (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, > > in pthreads generally etc.). It seems, the implementation will be tightly > > coupled with Lua and some specific form of IPC while abandoning simple > > interface for external bindings to languages with built-in parallelism. > I'm > > afraid it will not be possible to make e.g. such bindings for Dao ( > > http://daovm.net/) which would support the DaoVM parallel > threads/tasklets. > > > > In other words, I'm not sure, if all "public" methods/functions of the > BÖB > > API will be thread-safe and fully independent from Lua. Maybe I'm wrong > > about the goal of EFL 2.0, but I think, tightly coupling only with Lua > will > > certainly limit the utilization of these great libraries. > > > > Does anyone have some more accurate and detailed information? > > > > Kind regards > > > > -- Jan Pacner > > > ------------------------------------------------------------------------------ > > Rapidly troubleshoot problems before they affect your business. Most IT > > organizations don't have a clear picture of how application performance > > affects their revenue. With AppDynamics, you get 100% visibility into > your > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > > > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > _______________________________________________ > > 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" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
