On Sun, 29 May 2016 14:08:57 +1000 Peter <j...@zeus.net.au> said: > Thanks Carsten, > > Where's the best place to start looking to learn about Eolian? I've > done an initial web search which turned up some presentations. > > Is Eolian specific to Enlightenment, or are there plans for Samsung to > use it for other Tizen api's as well?
eolian is specific to efl indeed. we wrote it specifically for the object model we created and for the purpose of making bindings directly from source. consider this like gobject but with a very different take on how to do a generic object model in c. eo (the object model) and elian were built from the get-go to: 1. be able to back our existing code and so it requires specific and special solutions 2. to be able to act as a "language neutral" IDL system to define APIs that appear in C but also then map directly to other languages - be they statically typed or dynamically typed, explicitly memory managed or GC'd like C++, JS, Lua so far. 3. save us work in C by writing and maintaining boilerplate C code for us. this is old and eo syntax has changed since but it gives a bit of a general intro: https://phab.enlightenment.org/phame/post/view/75/yet_another_c_object_model_-_but_better/ we don't have the eo_do() construct anymore, but eo_add() can do the same by calling methods to setup up an object at construction time, so objects have finalizers to call after these setup methods are called. it's meant to be a way to optimize objects by deferring as much work f object creation as possible until the finalize when we know the initial state. if you find all the *.eo files in efl you'll see how it works soon enough: git clone https://git.enlightenment.org/core/efl.git cd efl find . -name '*.eo' -print those eo files. from those eo files C core/boilerplate is generated, and then the actual implementation code is filled in. from those eo files also the c++ *.hh files that are the bindings are generated as well as the lua files (we targetted luajit making use of ffi to bind), and if you --enable it, the js bindings (c++ v8/node.js code). for java i assume you'd want to generate possibly java code that uses jni to call the original c. someone has to write the eolian_java generator, but there is a libeolian that does all the .eo file parsing and manages an in-memory db of everything to make it easy. no - the rest of tizen doesn't use this. to date there has been no interest. they seem to prefer to do things by hand. > The JOGL library uses Gluegen to generate it's java bindings. JOGL has > a number of different back ends, I haven't quite got my head around how > to create a back end based on enlightenment yet, it did seem like a > difficult task. I looked at some of the gl application examples for > Tizen developers in Samsung's sample programs, but decided to focus on > creating java bindings for the Tizen api's first. hmm ok - so it's generated. the evas_gl stuff is plain c functions just as function pointers in a struct. the eo/eolian stuff doesn't cover it. doe to its nature it'd have to be manually bound. > I'm glad Enlightenment isn't written in C++. at least there are a few of you. :) > Regards, > > Peter. > > On 28/05/2016 11:01 AM, Carsten Haitzler (The Rasterman) wrote: > > On Sat, 28 May 2016 10:20:53 +1000 (AEST) Peter<j...@zeus.net.au> said: > > > >> I started writing java bindings for Tizen (on github). I was impressed by > >> the object orientated nature of Enlightenment and how easy it is to hand > >> craft java bindings for, following the inheritance hierarchy. Tools that > >> generate bindings don't do so well. > > orly? everyone keeps going "efl is not oo! make it oo! (rewrite in c++ is > > what they mean)". i keep saying oo is a concept independent of language. > > efl does do things relatively oo-ish. it could be improved (and thats what > > all the eo infra is for - now it looks REALLY oo with a single function for > > del/unref of every single object and direct strict > > inheritance/milti-inheritance and more). > > > > fyi - eolian should actually make it far easier to generate bindings. we > > already auto generate bindings for lua, js and c++ directly from the > > original .eo files for efl api. the .eo files are written at a high level > > abstraction and eolian generates/maintains the c boilerplate and there are > > various binding generators per one of the above languages. writing a > > generator for java shouldn't be too hard considering all of the other > > languages we are already handling. this means the core of efl remains c and > > there is a core c api with the bindings sitting directly 1:1 on top of this > > handling reference counting and more. considering the constraints of things > > like js and lua i think java should be easy. once you have a generator then > > maintenance is over. it's not just re-running it to pull out more api's > > into java whenever the libraries update and add classes and methods. we > > already run the js, lua and c+ > > + generators every time efl builds as part of the efl makefiles. > > > >> JOGL and JOAL bindings already exist, but I can't get access to a native > >> window on which to draw. > > as below - you will have to re-bind and make jogl etc. compatible api on > > top of elm_glview etc. it wouldn't be hard at all. > > > >> What I'd like is a standard way to get a window (full screen) on which to > >> draw using opengles. Events can be used to gracefully get out of the way, > >> suspend etc. I need some kind of compatibility layer between JoGL and > >> enlightenment to make it work. > > technically with is possible, but it looks more like: > > > > create window (elm_win), put elm_glview in win, show it, show win. done. now > > your window is filled with a glview. there are associated properties of the > > glview. > > > > it's actually FAR LESS code than using egl/glx+native xlib or wayland for > > example (as i've been doing this stuff for a long time... to do this RIGHT > > takes a fair bit of code like getting visual and colormap right in x11). > > far far less. > > > > the glview can allow you to use gles2/3 or 1.1 api on it (there is a > > complete gles set of api's in the evas_gl api struct). did you look at the > > glview examples in elementary_test? if you enable direct rendering fyi ... > > you get zero overhead support - no extra copies. the api funcs are almost > > all just direct pass down except a few like scissor stuff etc. - there is > > even a helper header that removed the need for glapi->func() and allows > > just the old func() via macros assuming a local var for the api struct etc. > > > > but either way for some java bindings this should do the work. > > > >> A headless jvm works, 2d and widgets will, but 3D I haven't figured out. > >> > >> Regards, > >> > >> Peter. > >> > >> Sent from my Samsung device. > >> > >> Include original message > >> > -- Carsten Haitzler (The Rasterman) <ti...@rasterman.com> _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
