[e-users] Few questions on EFL comparing to other frameworks
Silas Silva
I've recently been hired by a startup company. They plan to develop a
2D RPG game, with 2D characters that move on "blocks". A guys will make
the artistic part in programs for editing graphics, another will write
the plot, etc.
Since I'm the only one that got the development and programming part, I
have almost full power to chose the technology back-end. I was thinking
about using Qt (that I worked with during three years and I love it) and
maybe its embedded version or maybe Tk (from the Tcl guys), that I know
and like it too (specially the canvas object). The difference between
Qt and Tk is that the former is a full development framework and the
later is just a nice toolkit.
But, on LinuxCon in Brazil
(https://events.linuxfoundation.org/events/linuxcon-brazil), I saw a
very nice presentation from ProFUSION guys showing ELF, that I have been
very curious to try much earlier. I liked the presentation a lot
(specially the advocacy over Evas!) and, with this opportunity, I may
try using ELF.
So, I have a few questions:
1. What exactly the fact the ELF is LGPL means for developing
proprietary applications? May I link it statically? (Oh, after some
time back in the development world, need to re-read licenses...)
2. This game will probably not use Elementary. Since all the UI and the
game itself will be customized, we are thinking on using nice
features of Evas. An artist will use a GIMP-like program to develop
user interfaces, characters, menus, etc. May I show layers of PNG
images that have transparent regions? Any word on that?
3. MS Windows is the main target, but we want to develop it under
GNU/Linux and NetBSD and deploy it under Windows. I see ELF are
portable, right? What about "embedded" platforms like Android and
iOS?
4. What is the status of the C++ binding? Isn't recommended to use the
ELF C API inside a C++ application, is it?
5. How does ELF handles sound? Does it use lower level layers like
ALSA, OSS or multi-thread OSS?
6. Any word on my simple problem?
Sorry for the very basic questions, but I didn't have time to look
inside ELF documentation and try some examples yet!
Thank you!
--
Silas Silva
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
enlightenment-users mailing list
enlighten...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
David Seikel
On Tue, 29 Nov 2011 01:15:33 -0200 Silas Silva <sil...@gmail.com>
wrote:
> I may try using ELF.
It's EFL, Enlightenment Foundation Libraries, you got it right in the
subject though.
> 1. What exactly the fact the ELF is LGPL means for developing
> proprietary applications? May I link it statically? (Oh, after
> some time back in the development world, need to re-read licenses...)
Most of EFL is BSD licensed. Some parts are LGPL though. I think there
is a mix of LGPL 2.1 and 3.
> 2. This game will probably not use Elementary. Since all the UI and
> the game itself will be customized, we are thinking on using nice
> features of Evas. An artist will use a GIMP-like program to
> develop user interfaces, characters, menus, etc. May I show layers
> of PNG images that have transparent regions? Any word on that?
Evas supports transparency, but I'm not sure if it does at the image
level.
> 3. MS Windows is the main target, but we want to develop it under
> GNU/Linux and NetBSD and deploy it under Windows. I see ELF are
> portable, right? What about "embedded" platforms like Android and
> iOS?
I develop an embedded game using EFL, and like you I stopped using
Elementary. It was overkill for what I needed. I'm not doing Android
or iOS though, but built a custom linux from scratch.
The evil library is specifically for porting EFL to Windows.
> 4. What is the status of the C++ binding? Isn't recommended to use
> the ELF C API inside a C++ application, is it?
There is one, I dunno it's status.
> 5. How does ELF handles sound? Does it use lower level layers like
> ALSA, OSS or multi-thread OSS?
There is a new thing for handling sounds in edje, but it's so new that
it's disabled by default. Have a look at multisense in edje.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
Carsten Haitzler
> Hi all!
hey hey.:)
> I've recently been hired by a startup company. They plan to develop a
> 2D RPG game, with 2D characters that move on "blocks". A guys will make
> the artistic part in programs for editing graphics, another will write
> the plot, etc.
>
> Since I'm the only one that got the development and programming part, I
> have almost full power to chose the technology back-end. I was thinking
> about using Qt (that I worked with during three years and I love it) and
> maybe its embedded version or maybe Tk (from the Tcl guys), that I know
> and like it too (specially the canvas object). The difference between
> Qt and Tk is that the former is a full development framework and the
> later is just a nice toolkit.
EFL is also like tk.
> But, on LinuxCon in Brazil
> (https://events.linuxfoundation.org/events/linuxcon-brazil), I saw a
> very nice presentation from ProFUSION guys showing ELF, that I have been
> very curious to try much earlier. I liked the presentation a lot
> (specially the advocacy over Evas!) and, with this opportunity, I may
> try using ELF.
>
> So, I have a few questions:
>
> 1. What exactly the fact the ELF is LGPL means for developing
> proprietary applications? May I link it statically? (Oh, after some
> time back in the development world, need to re-read licenses...)
bsd allows static linking without problems. you don;'t need to provide any
source.
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
look in "differences from the GPL" for LGPL. "Essentially, if it is a "work
that uses the library", then it must be possible for the software to be linked
with a newer version of the LGPL-covered program. The most commonly used method
for doing so is to use "a suitable shared library mechanism for linking".
Alternatively, a statically linked library is allowed if either source code or
linkable object files are provided."
that's pretty much the take on that. so you must provide .o files for your game
so people can re-link to a newer static version of lgpl efl libs. you can also
just dynamically link and set up a launcher process or script that sets up
LD_LIBRARY_PATH so the .so's of efl you ship along with your application get
used and linked to automatically. efl is relocatable after compilation (just
try it out) and at runtime figures out its new prefix. ie prefix/bi, prefix/lib
and prefix/share relative paths are kept and you just change were prefix is. i
suggest this way as frankly - it's easier. you can use this technique with all
libraries and not worry about static linking issues and the fact that lots of
efl components require data files or module files and they use inspection of
their own symbols to hunt this down. static linking in some cases may simply
not work.
> 2. This game will probably not use Elementary. Since all the UI and the
> game itself will be customized, we are thinking on using nice
> features of Evas. An artist will use a GIMP-like program to develop
> user interfaces, characters, menus, etc. May I show layers of PNG
> images that have transparent regions? Any word on that?
yes. if the file loaded has an alpha channel then the image object reflects
just this. this is how all of efl works. everything you see in efl is almost
always composed of lots of layers of transparent images layered, stretched and
sized and tiled to give the ui look and layout you want. as such edje is a way
of taking these pre-made layouts and sticking them into a data file and loading
them as a whole object with all the layers intact. you can have the layers
changes and react based on messages and signals you send to the object -
internally the images and what not inside change to reflect a new state based
on whatever the edj file setup has in it.
edje allows you to do these ui elements with lots of layers and lots of details
scaling and layout controls and keep them out of the code and in data files you
can change/replace any time later even at runtime.
> 3. MS Windows is the main target, but we want to develop it under
> GNU/Linux and NetBSD and deploy it under Windows. I see ELF are
> portable, right? What about "embedded" platforms like Android and
> iOS?
no android or ios support. osx would work ok via x11 support that is in osx.
windows support is far from perfect - but it does get worked on and improved.
i'll be frank- the windows support definitely has bugs and issues and will not
support a lot of things like joysticks and exotic input devices. there is
currently no real working accelerated rendering on windows (it's opengl on
linux and i understand this works on osx too). so on windows u'll have software
only. also efl is quite slow to start up - it takes several seconds to start a
simple app. i'm trying to not get your hopes up here and to be disappointed.
non-linux support is, in reality, not a primary focus and consideration. there
is support for other os's and environments, but it's very much a 2nd or 3rd
tier effort. we'd be more than glad to have more people use it and help with
support on these platforms, but just realize that you may actually have to do
debugging and even fixes for some of these platforms. i'm just trying to be
realistic here so that you don't become disappointed because of high
expectations for non-linux support. on linux our support is rock solid and you
won't have issues at all. the less unixy your os - the harder it will be.
> 4. What is the status of the C++ binding? Isn't recommended to use the
> ELF C API inside a C++ application, is it?
i'd generally say using the c api is the best way to use efl. of course it
works inside c++. it just has a c api. that's all. c++ bindings give you a c+
+-like "oo" api to efl, but be aware they they will sometimes be incomplete and
not support some features the c api has.
> 5. How does ELF handles sound? Does it use lower level layers like
> ALSA, OSS or multi-thread OSS?
absolutely no api's related to sound right now in efl. you'll have to look
elsewhere for that.
> 6. Any word on my simple problem?
which problem?
> Sorry for the very basic questions, but I didn't have time to look
> inside ELF documentation and try some examples yet!
>
> Thank you!
>
> --
> Silas Silva
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> enlightenment-users mailing list
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Carsten Haitzler
> I can't answer all your questions, but I have some answers for you.
>
> On Tue, 29 Nov 2011 01:15:33 -0200 Silas Silva <sil...@gmail.com>
> wrote:
>
> > I may try using ELF.
>
> It's EFL, Enlightenment Foundation Libraries, you got it right in the
> subject though.
>
> > 1. What exactly the fact the ELF is LGPL means for developing
> > proprietary applications? May I link it statically? (Oh, after
> > some time back in the development world, need to re-read licenses...)
>
> Most of EFL is BSD licensed. Some parts are LGPL though. I think there
> is a mix of LGPL 2.1 and 3.
we have lgpl 3 in core efl? c++ bindings are lgpl3.
i guess epdf might be lgpl3 is you use the mupdf renderer. as such for
libraries we have released or now have beta's of they are either bsd-2 clause or
lgpl-2.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
David Seikel
<ras...@rasterman.com> wrote:
> On Tue, 29 Nov 2011 13:44:57 +1000 David Seikel <one...@gmail.com>
> said:
>
> > I can't answer all your questions, but I have some answers for you.
> >
> > On Tue, 29 Nov 2011 01:15:33 -0200 Silas Silva <sil...@gmail.com>
> > wrote:
> >
> > > I may try using ELF.
> >
> > It's EFL, Enlightenment Foundation Libraries, you got it right in
> > the subject though.
> >
> > > 1. What exactly the fact the ELF is LGPL means for developing
> > > proprietary applications? May I link it statically? (Oh,
> > > after some time back in the development world, need to re-read
> > > licenses...)
> >
> > Most of EFL is BSD licensed. Some parts are LGPL though. I think
> > there is a mix of LGPL 2.1 and 3.
>
> we have lgpl 3 in core efl? c++ bindings are lgpl3.
>
> i guess epdf might be lgpl3 is you use the mupdf renderer. as such for
> libraries we have released or now have beta's of they are either
> bsd-2 clause or lgpl-2.
I just did a grep. Looks like you are correct.
Ethumbd is not really core, but it's LGPL 3. I knew one snuck in
somewhere.
Carsten Haitzler
> On Tue, 29 Nov 2011 12:58:38 +0900 Carsten Haitzler (The Rasterman)
> <ras...@rasterman.com> wrote:
>
> > On Tue, 29 Nov 2011 13:44:57 +1000 David Seikel <one...@gmail.com>
> > said:
> >
> > > I can't answer all your questions, but I have some answers for you.
> > >
> > > On Tue, 29 Nov 2011 01:15:33 -0200 Silas Silva <sil...@gmail.com>
> > > wrote:
> > >
> > > > I may try using ELF.
> > >
> > > It's EFL, Enlightenment Foundation Libraries, you got it right in
> > > the subject though.
> > >
> > > > 1. What exactly the fact the ELF is LGPL means for developing
> > > > proprietary applications? May I link it statically? (Oh,
> > > > after some time back in the development world, need to re-read
> > > > licenses...)
> > >
> > > Most of EFL is BSD licensed. Some parts are LGPL though. I think
> > > there is a mix of LGPL 2.1 and 3.
> >
> > we have lgpl 3 in core efl? c++ bindings are lgpl3.
> >
> > i guess epdf might be lgpl3 is you use the mupdf renderer. as such for
> > libraries we have released or now have beta's of they are either
> > bsd-2 clause or lgpl-2.
>
> I just did a grep. Looks like you are correct.
>
> Ethumbd is not really core, but it's LGPL 3. I knew one snuck in
> somewhere.
it looks lgpl 2.1 to me - looking at COPYING in ethumb. i don't see any
copyright claim to the contract in ethumbd src...
actually it's kind of important we get these details right - especially by the
time something goes 1.0 - any license oddities we should clean up. GPL andd
LGPL3 are actually going to be very problematic in many cases and i'd basically
make this rule:
if its GPL3 or LGPL3 it cant be core efl. as such gpl3 is controversial
(discussion all on its own). any libraries that are GPL can't be core efl. LGPL
libraries are ok - must be 2.x. BSD is fine. mit-x11 is fine. libraries that
become GPL (epdf if using poppler, emotion if using xine module) are in a grey
"gotcha" land that if you configure and use them right won't give you trouble
here's the list of what i see is LGPL 3 or GPL 3:
enjoy
essekyuehl
elsa
azy
epdf IF mupdf is enabled
eyesight
e_pattern_lock
explicit
eon
quickaccess
ensure
escape
eskiss
econcentration
e_cho
cxx bindings
eve
espionnage
elmdentica
editje
excessive
detorious gtk theme
now is probably a good time to discuss licensing here. the above have not come
under the spotlight (yet) because they aren't core or required. when they do...
we'll have to figure this out.
as such random apps (eve for example) that are gpl3 are not a big problem, but
we can't ship it with e17 then for example.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
David Seikel
<ras...@rasterman.com> wrote:
trunk/ethumb/src/bin/ethumbd.c has, starting on line 6 -
* This program is free software; you can redistribute it and/or
modify it
* under the terms of the GNU Lesser General Public License as
published by
* the Free Software Foundation; either version 3 of the License, or
(at your
* option) any later version.
At least on my copy. Says version 3 to me, but my new glasses are one
month overdue.
> now is probably a good time to discuss licensing here. the above have
> not come under the spotlight (yet) because they aren't core or
> required. when they do... we'll have to figure this out.
True. but probably better discussed on the dev mailing list.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
------------------------------------------------------------------------------
David Seikel
<ras...@rasterman.com> wrote:
> On Tue, 29 Nov 2011 01:15:33 -0200 Silas Silva <sil...@gmail.com>
> said:
>
> > 2. This game will probably not use Elementary. Since all the UI
> > and the game itself will be customized, we are thinking on using
> > nice features of Evas. An artist will use a GIMP-like program to
> > develop user interfaces, characters, menus, etc. May I show layers
> > of PNG images that have transparent regions? Any word on that?
>
> yes. if the file loaded has an alpha channel then the image object
> reflects just this. this is how all of efl works. everything you see
> in efl is almost always composed of lots of layers of transparent
> images layered, stretched and sized and tiled to give the ui look and
> layout you want. as such edje is a way of taking these pre-made
> layouts and sticking them into a data file and loading them as a
> whole object with all the layers intact. you can have the layers
> changes and react based on messages and signals you send to the
> object - internally the images and what not inside change to reflect
> a new state based on whatever the edj file setup has in it.
Silly me, I had forgotten that some of the graphics I used in the lua
example make use of alpha PNGs. lol
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
------------------------------------------------------------------------------
Carsten Haitzler
oh there it is! i skimmed that quickly. as such there is no actual copyright
notice for gplv3 in the src tree - that kind of needs to be done and that means
copying needs to have gplv3 appended, or this needs to become gplv2 then.
> At least on my copy. Says version 3 to me, but my new glasses are one
> month overdue.
>
> > now is probably a good time to discuss licensing here. the above have
> > not come under the spotlight (yet) because they aren't core or
> > required. when they do... we'll have to figure this out.
>
> True. but probably better discussed on the dev mailing list.
aye squiddie
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> enlightenment-users mailing list
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Andreas Volz
Rasterman):
> > 4. What is the status of the C++ binding? Isn't recommended to use
> > the ELF C API inside a C++ application, is it?
>
> i'd generally say using the c api is the best way to use efl. of
> course it works inside c++. it just has a c api. that's all. c++
> bindings give you a c+ +-like "oo" api to efl, but be aware they they
> will sometimes be incomplete and not support some features the c api
> has.
I'm developing the C++ API (EFLxx). It's like raster said. It's really
usable for most EFL libraries. I use them everyday since some years,
but the API is still not frozen and not all functions are wrapped. It's
no problem for me, because if I need a new feature in my applications I
just enhance the API. :-)
But if you just like to concentrate on your application and never touch
the library, then go with C API for now. The C API is really good and
stable. But it's your decision!
http://trac.enlightenment.org/e/wiki/EFLxx
regards
Andreas
--
Technical Blog <http://andreasvolz.wordpress.com/>