On Sun, 9 Apr 2017 12:09:08 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> 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 Edje wasn't designed to do UI layout. it's incredibly limited in what it can ultimately do here and it just wasn't intended to do this. I think this is the job of something else to do other than Edje. Edje has expanded over time to the point it can kind of lay out some UI's - but thats just it being overgrown for it's intended use. :) > manually... Another clear example is Elementary vast widget library > and Enlightenment itself not using it. Yet another that is currently Actually it is. several e_widget's now wrap elm widgets. not all. i know ilist's, buttons at least are elm widgets underneath. the randr screen setup dialogs is 100% pure elm widgets btw... :) But really e's widgets should have vanished by now. At least what I imagined was a rewrite of the config dialogs using elm as the base while at the same time cleaning it up a bit and making it easier to use and find things. That hasn't happened yet. > 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...) Yeah. and that's why we've talked about merging efl even into a single .so/dll (and maybe allow different build options so it can be a minimal or full version with a subset or full set of api's/features). also if you look at eo/interfaces they are no longer looking like the old efl setup. evas was originally intended to be used by kde/qt and gtk/gnome people and thus it didn't have a mainloop idea or so on as i hoped people would integrate with theirs - but that was a mistake. so evas should know about time based stuff and that's actually being expressed now in efl.ui classes that do know this... :) > 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. this is all part of efl+interfaces - we're designing based on past experience with efl and apps, but it's not being used yet because it's not stable yet. one major bit of work will be in porting apps like terminology, rage, e, ephoto, edi etc. to eo/efl interfaces... it's certainly not a small amount of work. > 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. well they can';t be used until interfaces are stable. we break the eo based api's a lot and you just can't use an api that changes so much as you are continually catching up doing work you just don't want to do. getting these stable and saying "it's close enough - we'll have to live with that" is probably the most important thing to do here. once that is done, that opens up the existing c++, js and lua bindings for use. this is why this is so important. and even if we get our current targets done, there is work to do after this: 1. multiple efl.loop objects. this is a continually asked for thing - to have better threading support and to do this well we need this. have multiople loops (with the main/ui loop being for ui) and have everything probably done as inter-loop messaging and/or execution (run this function in this other loop etc.). atm our threading support isn't bad, but it's a bit hard to work with in some ways. 2. ethumb probably needs to just be hidden behind efl.ui or maybe a lower level o class - likely be replaced as we just can't work with a dbus service as this unfortunately violates several MAC systems - thus thumbnailing has to be done locally per process (as a thread or slave child helper), and possibly thumbnails stored in an application-private location (or a named private location that could be keyed off app name or credentials). 3. efreet needs a rethink for portability etc. and we should find a nice way to expose this via eo... so likely a rewrite here probably recycling some of efreet code (ini parser etc.). 4. we probably should reconsider eeze's api as it's not totally portable (exposing sysfs paths is not a good thing). At least the back-end should be written to be portable. udev access probably/maybe should be moved to a thread too. we likely can reuse some of eeze's code and api design, but we do want to expose this in an eo way and that means a rethink like the rest of eo/interfaces work. 5. eio/ecore_file really should become an eo based file i/o and manipulation api of some sore. either way with eina apis, eio and ecore_file our file access/manipulation api's are a mess and need cleaning up. 6. what about ecore_avahi, ecore_buffer, eet, eldbus, elocation, emile, ephysics ... at least some of these should become eo/interaces like api and wrapped or redesigned. some maybe not. Either way there is work to be done even once our current set of interfaces work it complete. Oh and a big big thank you to the work you did on ecore_con (efl.net now). In this regard as this checked off one item from the list of stuff to do... :) > 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 Well that's not what all people say. Many say Edje is very hard to use and they just don't want to do Edje - they want to do everything in code and not have to jump/leave their current source code they are working on... so there are other points of view too... :) > 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...). Yeah... this is one way to do your GUIs - design your own to be custom for you and your app/brand/company/project... the other is the below. Try and "fit in" and look standard. :) > 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. Is it an old need? At least on OSX and modern Windows apps are encouraged to fit in and look "standard" and users want it there... :) > [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. Ok. There are multiple ways of looking at it... just saying. :) > # 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! Edje doesn't have anywhere near enough controls or features to do this... and as I said above - wasn't designed to do it to begin with... I think we need an alternate solution for this somehow. I think we can stuff it INTO edj files (they are just eet files), but the support in Edje is far too thin to do a proper UI. Edje is already creaking at the seams. It's grown much bigger than I ever imagined and it's due for a major rethink. I wouldn't want to add more to it nor add more and more things for it to do. > 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). Well that's a question of "what is it simpler to solve in". Do you write a bunch of classes/methods or whatever to expose config to bindings or just do the UI in C. I think it doesn't much matter. BUT I do agree with you mostly on gadgets. But I think it's not a matter of writing them in JS, or Lua or Python only, but we should move these out out process. The display part can be in-process or use ecore_evas_extn to display remote canvas content... but I'd actually like to get most of these gadgets and modules out of e's process into a "backend slave executor". A single process will do, but one that could load snippets of Lua that will poll batteries or what not and tell the UI what to do (or directly render a small gadget in a extn canvas). > 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... As above - Lua is the most viable due to it being a core dependency of EFL already and it's size. But I don't think we should go rewriting apps in Lua (or JS etc.). I think language is a choice the developer of an app is going to make and that's personal. Enlightenment is big enough to warrant a lot of extensions and supporting Lua for these would be a very good thing IMHO. Rage just has no good reason to do anything with Lua. Terminology I don't think so either. I do encourage people to write apps. People are writing them in Python as the bindings are stable. The JS, C++ and Lua ones are not due to eo+interfaces not being set in stone yet. Until this happens it's not useful tyring to ship apps written in these languages and bindings. One they do solidify then it's a definite possibility and I'd encourage it. This is where I'd like to see us make an on-line app sharing mechanism for EFL. If you have EFL (or a version new enough) then writing an app should be easy and guaranteed to work. Then being able to share apps with others and download them becomes important. Having a single cross-platform way of doing this would be the way to go. Tools to package and share an app you wrote. Tools to start a new app and fill out a template for you etc. - Eventually extend this to writing modules for E and share/download and so on. But it does all hinge on getting interfaces stable so this can happen and apps not break. Once this is stable I think we should concentrate on extending our eo interfaces to be as full as possible, then have E be able to load e.g. lua modules by exposing bindings of its own to the lua it loads in addition to full efl interfaces. the back-end executor would also be a good thing to have. My questions would really be: 1. should an appstore be part of extra or separate? on the server-side i don't think it much matters, but where should be stuff an appstore client? 2. should appstore be separate, ship with efl or ship with e? where does it belong. i lean to shipping it with efl... :) 3. who will write what apps using efl? > 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... i have to disagree with this. :( > - Could we commit to create app internals in Eo? At least the core > functionality that could allow high level languages in your app. can you explain this? "create app internals in eo" ? > - Could we call "Lua is the official EFL binding and > E/Terminology/Rage/Ephoto... uses it"? i think this is going to happen in baby steps. i do see E making use of this once interfaces are settled. it is by far the best solution for having downloadable apps that use efl that will run everywhere. i see no use for rage at all for it. for terminology i don't think it's worth it. for ephoto - i don't know but i don't think so. just because an app exists does not mean it should be extensible by arbitrary code. surely large things like e for sure. smaller things - not so much. i do think we should make a start on using lua ONCE interfaces have settled to being stable :) with the eolian infra it makes it reasonably nice to expose extra application specific bindings to lua too... :) > - Could we eliminate all custom FS -> List/View code paths and use > the MVC that gives you that? i think that's kind of underway... > 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... realistically all of this hinges on the eo/interfaces being done and stable. given that, more is possible. i absolutely agree with you on the gadgets side of e and i want to go even further and move lots of that stuff to a slave process (and that can also run lua and now be even nicer as if the lua happens to be bad/slow it doesn't impact the main wm). as i said - realistically lua solves the "distribute apps portably" problem for us. that will allow us to create an app distribution channel that installs apps in your home directory without root access, and that allows direct from developer -> user distribution without going through distributions. it doesn't have to be packaged N times nor get sign-off from distro devs. it does limit what can be written but it'll still be a big step in the right direction. i think it is OUR job to begin populating this repository of apps ourselves. that would mean writing them in lua. i'm not so sure larger complex apps should be written in such languages but definitely smaller utilities for sure. the good thing about the small apps is they can be created quickly and would serve to scratch itches fast... so we could grow a population of useful utilities fairly fast. so at least partly i agree with you. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
