[Dev]   SDL support on Tizen

Peter jini at zeus.net.au
Mon May 30 06:41:41 GMT 2016

Thanks Carsten,

Yes java jni code generation.  Thanks for the references this helps a lot.

It's a shame Eolian use doesn't extend to Tizen api's, perhaps Samsung may reconsider? 

Samsung: Automation trumps manual editing every time, the parser and generators will end up being thoroughly tested in the long run, significantly reducing bugs and saving many wasted development hours that could be spent on more important work.  

Having the worlds most popular programing language running on Tizen makes a lot of sense too (It's the language of Android).  Tiobe index:

Java 21%
C 13.2%
C++ 6.7%
JavaScript 2.3%
Swift 1.6%
Objective-C 1.6%

Java and C are the only languages with market share in double digits, these two together have more than one third of total developer market share. 

The increase in Java last year alone (+4%) was almost twice the total for JavaScript.  

Increasing available apps is more likely to occur if you double the number of developers who can write programs for your platform.

It would make it a lot easier for developers to create native ports of Android apps, provided the presentation and application layers are cleanly separated.

Most recent UI's can be defined using xml, including Android, JavaFX and Apache Pivot, among many others, which does make me wonder if generators can be written to transform these into enlightenment ui components for simple applications, the parsers already exist and are open?  Far superior to android emulation.

The jvm and libs can be stripped down using compact profiles and jvms can share class files to reduce start up time  The jvm is 2x faster than Android, although I believe startup can be slower for Java.

JOGL supports both Jvm and Android platforms for 3D cross platform compatibility.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Carsten Haitzler <tizen at rasterman.com>
Sent: 30/05/2016 10:58:08 am
To: Peter <jini at zeus.net.au>
Cc: dev at lists.tizen.org <dev at lists.tizen.org>
Subject: Re: [Dev]   SDL support on Tizen

On Sun, 29 May 2016 14:08:57 +1000 Peter <jini at 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 
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 


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<jini at 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) <tizen at rasterman.com> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20160530/1bb6a3b7/attachment-0001.html>

More information about the Dev mailing list