To focus on very specific items that you mentioned: I did some exploration into using eo/lian in enlightenment a few years ago and instability immediately proved that this was a waste of time. I have no interest in revisiting or considering anything related to eo/eolian/bindings/interfaces/etc until stable releases have shipped with compatibility guarantees.
Your premise that enlightenment does not use elementary is false, and it has been for a few years. The legacy e_widget apis remain, but widgets uses elementary internally where possible. This was done to avoid having to rewrite the entire gui at the same time as doing the widget conversion--a separate and much larger task which is still pending. There are exceptions to this, namely ilist (which would have required significant and invasive rewrites to convert to genlist) and e_icon (which, at the time, provided features which were not present in any single elm widget). All new code added since then, e.g., gadgets, does not use e_widget apis. I agree that binding support is useful, and I plan to provide support for other languages in modules (again, I have no interest at all in discussing or considering technical details of this until stable releases of related apis are shipping). I do not, however, plan to rewrite any part of the core using a language other than C. On Sun, Apr 9, 2017 at 11:10 AM Gustavo Sverzut Barbieri <barbi...@gmail.com> 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. Yet another that is currently > being addressed is Evas x Ecore, although Ecore existence would > simplify Evas immensely, we carried on without such strict dependency > for more than a decade, which not only made Evas more complex, it also > resulted in yet-another-library (ecore_evas) and many other spawns > (ecore_input, ecore_evas_input...) > > Historically we have few apps other than our window manager, which as > said above uses lots of low level APIs, and the few apps we have also > use some sort of low level features, such as Terminology, Rage and > even Ephoto. For instance, while we're creating Eo "MVC", no app is > using that.. replicating stuff like file system walk/scan for files, > then presenting them in list/grid views. > > In the last 10 years companies started to look more into EFL due its > technical aspects, being used in Tizen/Samsung, Electrolux Fridge, > Zodiac Aerospace infotainment, Calaos Home automation and so on. A > common request is to improve its usability, which resulted in Eo and > many bindings, from manual Python to JS/elev8 to now automatically > generated Lua/JS/C++. However, none of them is used for real. > > Since most EFL developers came from previous GUI toolkit experience, > we try to replicate what existed in here... this resulted in > Elementary being an extremely huge set of widgets trying to do many > features at once and that resulted in a hard to use, hard to customize > experience. While in GTK/Qt (not QML!) you need to create a series of > boxes/containers and then a button to have a button or icon on your > screen, otherwise the positioning wouldn't be flexible/scalable... in > EFL we do have Edje (also exposed via elm_layout) which allows you to > do that in no-time... with the looks you want, matching what all these > companies want (if you look at iOS/Android, most apps have their > custom looks, rather than a "desktop look", which happened to > influence most of desktop applications on Windows10 and MacOSX...). > But we're trying to match the old GTK/Qt, with pre-canned solutions of > all possible combinations and the result is that to theme a simple > button you need to deal with multiple EDC Groups, Parts and Signals > (icon, text, icon + text...). Net result is our code is much more > complex than needed because we try to address an old need and this > inhibits our potential usage of the new needs. > > [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. > > While most API was ported to Eo in a "simplistic" way, basically > rewrapping the same code in Eo with different namespace, like using > "efl_" and providing a different "legacy: xxx" prefix, some changed > for real like my "efl_net" and "efl_io" classes to replace old > ecore_con. Evas and Elementary also have some bigger changes, thus > automatic or naïve ports are not recommended. > > During UI port, take the time to convert from manual traditional UI > packing (create box, pack inside another box, with another box... > setting alignments) to and Edje layout. You can use things such as > EXTERNAL parts to automatically instantiate the widget for you, then > you simply access them. Custom widgets can be exported by your app, > then Edje just uses that, or you can use a SWALLOW and manually put it > there. You can use tools such as eflete to visually do it... see your > code be reduced by great margin, just care about feeding data and > events to the proper parts! > > Eo also gives us automatic binding generation, then try to define your > own classes for your code, this would get you some high level language > to deal with in the rest of your code. For instance, when we think > about Enlightenment, there are all the widgets that could be converted > to use new Eo, but most of the dialogs and configurations have ZERO > need to be written in C... however you can't access E_Zone, E_Config > and the likes in Lua. If during that process we create Eo wrappers for > those, we'd get the EOID pointer safety AND bindings, which would > allow most settings and shelf/bryce gadgets to be written in high > level languages, which are safer, faster and requires less code (to > write and to maintain). > > 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... > > Last but not least, Edje is super nice for UI design, we have tools to > edit it. > > # 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 have a rule to favor "Elm_Layout" rather than Box/Table > and old manual patterns, if possible having common layouts in > Elementary itself, like "toolbar + content" or "toolbar + panel + > content" kinds... > > - Could we commit to create app internals in Eo? At least the core > functionality that could allow high level languages in your app. > > - Could we call "Lua is the official EFL binding and > E/Terminology/Rage/Ephoto... uses it"? > > - 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, all that we get is more of the same, > investing effort in multiple sites that do not benefit the rest of the > platform (ie: FS->List/View in E, Ephoto, Rage... all with its perks), > Lua bindings never getting "reliable" since there are no users, there > are no users because it's not reliable... > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 <+55%2016%2099354-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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ 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
