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 ------------------------------------------------------------------------------ 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
