On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri <barbi...@gmail.com> wrote: > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <sfl...@suse.de> wrote: >> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>> Which brings me to my last point: we should adopt and use for REAL a >>> binding. You all know my personal preference is Python, but in 11 >>> years I couldn't convince people to like it... so whatever people >>> like, let's pick one language and use it as much as possible where >>> appropriate (you're not rewriting the core of Evas in it...). It seems >>> Lua is strong contender, and is very efficient, small and already a >>> hard dependency... our docs are being generated by a lua script, >>> etc... >>> >> openSUSE ships atleast 4-5 applications using the python bindings and >> could probably ship a few others from bodhi. (We don't at the moment as >> they don't have a proper build system and I haven't had the time to port >> them too one). I personally also prefer the python bindings and have >> used them in the past. > > I'm a python guy, wrote the initial python efl... I wrote big software > using that (Canola 2.0 if people remember of that) and tried to push > them as E modules... never sticks, particularly Rasterman never liked > it, thus a major developer who would never ever touch it -- and this > defeats the purpose. > > Lua isn't bad, and as it's required to build and during efl's use, we > can stick with that. Like making it zero-cost/effort to enable lua > scripting in every application, reducing the pain to write simple > stuff like basic configurations.
I like the idea of having a zero-cost/effort to add scripting support in any EFL application. I don't know yet how easily we can do that. I guess that maybe some of the binding should provide a library as part of EFL to make it easy to do integrate them. Something doing initialization, registering object, loading a script and executing one for some amount of time. I am also not sure about lua at all here. I know we are focusing mostly on performance, but if we really care about increasing our developers base and making it easier, isn't JS the winner in that space ? Isn't it over already for choosing the scripting language ? > Take terminology as an example, while the core VT handling is > something I'd keep in C, all of those settings, tab management and > even mini view layout could easily be Lua. Of course allowing the > terminal handling itself to be extensible in lua would be awesome, > like plugins to do search, highlight and preview... even allowing > tyls/tycat/... kind of escape extension to be handled to the plugin. > > Extra is likely an app that could be fully written in the high level > language, maybe Rage is in that front as well. While Ephoto could use > it for everything but the image filtering (actually that one would be > better suited to some kind of filtering abstraction that would execute > in CPU or GPU). Here is a slightly different idea. Instead of adding scripting to all our existing application, what if we extend extra to also deliver sandboxed JS/Lua applications. It could be very neat if we could on this sandboxed application contribute patch on it in almost one click. I think this will solve one of the core limitation of working on native technology, the long cycle between when you are done writing a patch and the time your users see it and also the ability for users to easily contribute to it. I know that GNOME is going on the very hard road for this and trying to make sandboxed application using systemd and all the infrastructure. It would be neat to support this environment in Enlightenment, but I don't think we have the man power to do so. Sandboxing JS and Lua, together with some sort of application delivery seems much more doable with the team we have, but I may be wrong. -- Cedric BAIL ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
