On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <[email protected]> wrote:
> 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.
yes, but my point below is when we do that, try to do in the highest
possible way, like using lua, mvc whenever appropriated, etc.
>> [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
Sorry, I forgot to define a timeline for that. This is future, post
Eo-stable and likely when we mark all old/legacy as deprecated...
still ongoing discussions if that's going to happen by end of year or
whatever, but it would be bound to that (as well as other points, such
as eolian/lua/mvc working properly)
>> 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.
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).
>> # 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.
well, history shows it never happens due lack of manpower, interest
and all. At least for E, once elm was released we all thought it would
quickly replace all E dialogs since it was much easier and powerful...
we got things like elm_prefs to speed up that process, but it was
never used. (ok, we lack manpower and thus touching whatever is
working is less likely to happen).
maybe by committing to this and having that as an action plan to
validate the Eo stuff it will happen... after all we'd be releasing Eo
as public/stable but our only use is internally... kinda of not a real
world validation...
>> - 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
actually you'd be rewriting the code to use the new API anyway, so
doing that in Lua should be less work or a "sed" (it's not 1:1, things
like Ecore_Event is gone, then callback signatures changes, some
behaviors as well).
This is particularly true if moving to higher level features. Like in
ephoto, if MVC and Lua bindings works as advised, there is not much to
do in code other than some navigation and linking of views.
> but maybe you could encourage it for new projects.
sure, but here history hits again:
- usually when it's not used anywhere else, when people try to use
it, they will find roadblocks that will push them out of that path.
For new projects, there are new ideas, which could fail... it's 2x
harder ;-) for existing projects you "know it's possible and how to
make it", if the new API or bindings don't allow that, there is an
easy to report bug.
- core devs usually postpone and push that to other people... never
getting to that themselves... that sticks us to C, more code, more
bugs, less developers that could help (particularly true for newbies).
> 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.
yes, I pushed for that long ago, I guess someone made it for real at
some point... but never picked traction.
looking at shelf gadgets, almost all of them are doable in such high
level languages... if we have eldbus and ecore-con exposed, then
pretty much all of them could be done. Some would need E internals to
be Eo-ified, like pager/ibar would need WM info. But connman, bluez,
batter, clock, temp, package manager... could be all done without much
extras.
for e_config stuff we could benefit from existing Eet_Data_Descriptor
and write a lua converter that would allow its usage even before it's
converted to Eo... like:
e_config_set("/path/to/key", value)
value = e_config_get("/path/to/key")
then it would split "/path/to/key" into pairs and navigate the EDD,
get the offset, type and convert to/from lua.
>> - 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.
Developers disagree on how to get Eo out... this is another issue. My
personal take on this is we should sync everything for a while and
force strict version dependency of all apps and EFL until it's fully
done.
As I said before, Eo it's just being tested internally in EFL and
mostly used to convert existing code in a simplistic way, like a new
namespace, use EOID pointer indirection and events... rare cases we
use common interfaces (mostly in Evas and Elementary).
But once used more aggressively, new needs will come... it was clear
during my write of Efl_Net/Efl_Io... I came with many requests, found
bugs and enhancements... q66, cedric and Tasn were kind enough to
address them. But I think once it gets broader usage, more of that
will show. Promise/Future is clearly another one that will show its
issues once more people use it.
If we try to provide "super stable, never breaks API/ABI" it will
impact immensely the small development team we have and you can expect
1.19-like experience for all other releases.
Given that we have very few 3rd party apps "in the field", my
suggestion is we allow breaks, bump soversion, change soname,
whatever... and apps stick to that. At least for few (2-3) releases of
Eo, then we can go back to stable and backward compatible ABI.
> 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?
Those who committed? At least that's my PoV... kind of "suffer once,
benefit will come in the long run".
That's why I'm insisting on the "rewrite stuff", this will allow us to
much quicker iterate, detect problems and fix them. Most of our apps
are not extensive, the bulk of development time was used to find good
usability, figure out architecture... these would not be lost in the
rewrite. If we focus on doing that during a period we can also improve
documentation and experience sharing (currently very few devs know
Eo/eolian/bindings well).
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
