On Mon, Apr 10, 2017 at 11:13 AM Gustavo Sverzut Barbieri < barbi...@gmail.com> wrote:
> On Mon, Apr 10, 2017 at 11:16 AM, Mike Blumenkrantz > <michael.blumenkra...@gmail.com> wrote: > > 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. > > yes, the common assumption is this all depends on more mature eo. > > Backward compatibility will take more time as without real world usage > we cannot claim it's fully ready... it would mean us to carry a > potentially big pile of crap of pseudo-legacy. > > I see this will be the biggest hurdle... chicken-egg :-/ > I think there are bigger hurdles, like manpower availability. > > > > Your premise that enlightenment does not use elementary is false, > > What I mean is that E wasn't converted to be pure ELM, e_widget is > still there as you said. > There will never be a conversion, the users of e_widgets will just be replaced. The only things which really use it are the config dialogs and old gadgets, both of which have been or will be rewritten. > > > > 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). > > I get that and we're under-powered, then priorities need to apply. > > but that may be even of help with my approach: since you need to > rewrite to ELM and some changes are invasive... would you consider to > rewrite those in higher-level language and infrastructure? > > by infrastructure I mean things like "*.epc" (elm_prefs). IMO we > should pick that, add what's missing and put to usage... it's meant to > simplify simple configurations while allowing extensions to produce > complex. > > > > > 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. > > by core I guess you mean src/bin, then okay... since most dialogs and > other stuffs are modules anyway. > > > > > -- > 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
