Thank you. If I got it correctly, it will be possible to use BÖBs C API
from parallel threads without being afraid something will break up. That's
neat and I'll look forward to testing first alpha versions in a few years
:).
2013/12/16 Carsten Haitzler ras...@rasterman.com
On Mon, 16 Dec 2013 06:25:54 +0100 Thanatermesis
thanatermesis.e...@gmail.com
said:
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 ?
i have seen many people propose edje as the solution to glade - as a
complete
ui builder solution. i've seen them expect it to do things that elm boxes,
tables etc. etc. do and do it completely. it's very hard to do synamic
layouts
(lists etc.) purely in edje. it's designed mostly around an element with a
fixed number of things (labels, etc.) and a fixed known number of states.
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 ?
above. they expect it to be a replacement for glade and/or qml etc. etc.
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
