On Sun, 15 Dec 2013 17:48:37 +0100 dumblob <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
