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?
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.
I'm glad Enlightenment isn't written in C++.
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
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
