On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: > Hi all, > > Nowadays with a newborn daughter I have more time to think than to > code (likely to remain like that for few more weeks), so I did think a > bit more of our development process in the light of "how to make it > faster, more reliable and easier to use". > > As most of you that join IRC at the same time as I do know, my idea is > to use more of our high level features, including our high level > languages. To elaborate: > > # Background > > Historically in E/EFL new features are developed based on needs, like > Evas was created to address Enlightenments fancy graphics and > particularly EFM... this also resulted in need for theme engine which > resulted in EDB, EET, Edje... The main loop abstraction resulted in > Ecore, the widgets need resulted in Elementary. > > However, also historically although the features are developed to > address some needs they are not used up to their potential. For > example, if you know Edje's potential you'd be amazed how much of that > potential is wasted in E, with many layouts and design being done > manually... Another clear example is Elementary vast widget library > and Enlightenment itself not using it.
Enlightenment is using it in some places and some E widgets are no longer used, however given that the plan is to rewrite the all the configs anyway no one has bothered to replace them all with elementary, once this is done then e widgets will likely be removed. > [Personal experience here: from 2007 (pre-elementary) to 2014 I worked > creating EFL-based products, all of them were "new UI" post-iPhone was > released and Edje excelled to allow developers to implement the > fanciest designs in short time with excellent performance. From > 2008-2014 we always evaluate Elementary, often we mix that with our > Edje-based views, but what happens to be worth is mostly > Genlist/Gengrid for large volume of information and Entry to handle > text input. Buttons, Box, Table are very rarely useful when you need a > fancy UI] > > What was done is unchangeable, no explanations on "why", no excuses > are needed. But I'd like to change that to a brighter future. > > > # Proposal > > With Eo becoming more mature and the new APIs getting out of beta, I'd > like to take the opportunity to convert our usages to the highest > possible language AND technology while porting. > We can't use eo in releases of anything like terminology, enlightenment or anything else with a release until its api is stablaised, if you want to push the adoption of eo the #1 thing that needs to happen is its api needs to be stable for efl 1.20 so people can actually use it without having to re release every efl version. I for example won't ship any eo apps in openSUSE because until the api is stable its too much of a pain > > 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. > > # Commitments > > To address that I'd call the following commitments from the community, > we can create a poll on phab to track popularity. My items are: > > - Could we commit to create app internals in Eo? At least the core > functionality that could allow high level languages in your app. > Once it has a stable API I think you'll start to see it happen, based off the fact Terminology had some added and then removed again due to not working with release builds of efl. > - Could we call "Lua is the official EFL binding and > E/Terminology/Rage/Ephoto... uses it"? > Its probably unlikely you'd get people to rewrite existing code in another language for the sake of using another language but maybe you could encourage it for new projects. At one point there was a enlightenment module that would let you write other modules in python, maybe something like this for lua would be a good starting point. > - Could we eliminate all custom FS -> List/View code paths and use > the MVC that gives you that? > > From IRC talks it's clear that our technology is not there yet, of > course Eo needs to be declared stable, eolian_lua needs some work and > MVC is still immature... but my bet is that unless we commit to the > above these will never happen, > The reason the 1.19 release is now dragging out to 7 months is because eo hasn't been declared stable and from what it seems like know one has the time to put in to get this finished. As a result releases are harder because some apps like eflete and enventor are using eo and whenever efl is released we need to sync there release as well. So my main question is if we have a poll and the community decides on what should be done, who is actually going to step up and do it? -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
