On Sun, Apr 9, 2017 at 9:51 PM, Simon Lees <sfl...@suse.de> wrote: > On 04/10/2017 12:21 PM, Gustavo Sverzut Barbieri wrote: >> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <sfl...@suse.de> wrote: >>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: >>> 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.
One of the thing we are trying to do with EFL new API is to reduce the amount of code you have to write. I will write another email about all of this later this week. > Well my personal experience from working on large scale software > projects suggests that for larger projects you don't want too high a > language as loosing your compile time type checking etc tends to lead > towards more bugs and less manageable software. That is why personally I > prefer C++ or maybe C for larger projects, I guess for some E modules > you could probably get away with it. As with smaller elementary based > applications although if I was going to write one I'd probably use python. I fully agree with you here. With javascript, I know that anything more than 1000 lines of code is impossible to manage at all. The reason why it "work" is that it mostly fail silently and kind of continue to work. Modern C++ is really great in term of automated checks at compile time and EFL C++ API looks pretty neat to me for new application, but the issue is that you can't easily share application and module across system without recompilation. > That however, just brings us to probably what is your bigger hurdle, > Enlightenment developers tend to be old and grumpy and still like to do > everything in C for reasons that escape me :-P Yup, and even C++ is to modern for most of them :-) >>>> - 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. > > Speaking with a distro maintainers hat on I will simply say that idea is > Madness and can't happen :-P (Being like that with 1-2 apps is hard > enough already). > > The only way we can move forward here is if we can get a api we are > willing to call stable then release it. I do agree on both of your point, but I also think that Gustavo is right in the sense that we need to exercise our API not only on EFL internal, but also in real life application. I think for the time being, our best solution is to maintain experimental branch for all of this application that makes sense to be simplified by the new API. -- Cedric BAIL ------------------------------------------------------------------------------ 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
