EWOL has a C++ architecture that allows for maximum flexibility.<br/>
The main idea of EWOL is to create a complete abstraction of the platforms.
This generate some restriction that you will see an overwiew in the under section.<br/>
<h2>User requires:</h2>
To use ewol you need to know only C++ language. It could be usefull to know:
<ul><li><spanstyle="font-weight: bold;">Python</span> for all build tool.</li><li><spanstyle="font-weight: bold;">git</span> for all version management</li><li><spanstyle="font-weight: bold;">OpenGL-ES2</span> if you want to create custum advenced widget.</li></ul>
<h2> Architecture:</h2>
One of the important point to know in this framwork is some of absurd things came from the multiple architecture type.<br/>
<ul><li> IOs does <spanstyle="font-weight: bold;">NOT</span> simply support the shared object sub lib, this force ewol to be APACHE-2, and depend on some sub-library with small license restriction.</li><li> Android have a JAVA main, then the application main will not be used with this platform</li><li> Android event (keyboard, mouse, touch-screen and ...) will arrive in asynchron mode ==> need to be resynchronyse in one thread</li><li> Only one graphyc framework is availlable on all platform. This is OpenGL</li><li> Main interesting point is packaging of the application data:</li><ul><li> Linux store it in /usr/share/applName/*</li><li> MacOs store it in applName.app/subFolder/*</li><li> Android store it in the .pkg that is a renamed .zip that the name is dynamic</li><li> Windows (TODO : Never done a pakage)</li> This will generate a complex result of data access...
</ul><li> Sub lib Change on all the platform, the I will use the idea of Apple, that incluse in a package all needed libs. This could be a problem for small platform, but this framwork need to have a OpenGL-ES2 instance then the memory problem, is not really a problem.</li></ul>