On 03/05/2013, at 23:22, Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Fri, 3 May 2013 13:37:18 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> On Fri, May 3, 2013 at 12:38 PM, Carsten Haitzler >> <ras...@rasterman.com>wrote: >> >>> On Fri, 3 May 2013 12:03:22 -0300 Gustavo Sverzut Barbieri >>> <barbi...@profusion.mobi> said: >>> >>>> On Fri, May 3, 2013 at 8:35 AM, Cedric BAIL <cedric.b...@free.fr> wrote: >>>> >>>>> On Fri, May 3, 2013 at 8:13 PM, Gustavo Sverzut Barbieri >>>>> <barbi...@profusion.mobi> wrote: >>>>>> It is not about generating code, people just don't get it >>>>> >>>>> For people to get it, we need many things to improve the situation in >>>>> Elev8. We need to polish its introduction in Enlightenment and provide >>>>> an easy way to distribute gadget/apps. Along with some documentation >>>>> that would help spread it and show case what it is good for. >>>>> In my opinion JS is not a tool good for everything. Any application >>>>> that require a team to maintain it over time with a more than 1000 >>>>> lines of code is going to suffer with it. Hopefully that still leave a >>>>> lot of application possible. I am thinking about all the configuration >>>>> tools here : connman, cups, transmission, ... It should also be good >>>>> for webservice integration like reddit and friends. And finally it >>>>> should be good for casual game to. We should be able to code elemines >>>>> or efbb more easily in Elev8 (We need an easy-game helper maybe :-)). >>>>> But JS wont be good for an integrated communication suite, an IDE, a >>>>> web browser, ... So we need tool to help the development of both side. >>>>> In the JS/EasyUI world, it is mostly integration with E and >>>>> distribution of application. In C, it is more an IDE that we need. >>>>> Both work are orthogonal in my opinion. >>>> >>>> This is complete nonsense. With JS you can modularize as well as in C, >>>> actually the language constructs makes it easier to modularize. >>>> >>>> The performance of a hundred thousand lines of code with JS is not an >>>> issue, as the sensitive areas are basically done in C (with elev8/efl), >>>> also the V8 can optimize quite well some loops and access, thus moot >>> point. >>>> Moreover, from the hundred thousand lines case, you're often executing >>>> small parts of it at the same time, afterall you can't fit much in one >>> user >>>> screen. >>>> >>>> As for your points "JS won't be good", let's review it with reality: >>>> - communication suite: the best communication suite out there is >>> written >>>> in HTML5 + JS, it is called Gmail + Gtalk >>>> - an IDE: adobe and others disagree, http://brackets.io/ is fully JS >>> and >>>> HTML5. Let's not forget that we both use Emacs, that is written mostly in >>>> Elisp, that is far from being as optimized as JS nowadays; >>>> - web browser: the browser itself is a very thin layer, I can't see >>> why >>>> a browser chrome couldn't be written in JS.. the heavy work is all in >>>> WebKit/Blink, you just need to get some signals and update the title, >>>> progress... >>>> >>>> I just don't understand why people don't understand. Also I don't >>>> understand why I still bother to write this stuff. >>> >>> performance wise js is fun as long as you can pass off the heavy lifting to >>> native code and it's doing the logic/direction at the higher level. no >>> problem >>> with that. >>> >>> the issues here are: >>> >>> 1. the actual target audience is currently developing apps with efl as >>> native. >>> they like it that way. they want it that way. changing that desire is very >>> hard, so let's service the desire and make things easier >>> 2. the intent is to support elev8 later as well, but first service the >>> desire >>> of the people who are paying for it. >>> 3. it's impossible to sensibly tell people to "write in elev8/js" vs native >>> because it is so limited/crippled right now. we have a long way to go to >>> fill >>> it out with functionality first so it can be even close to native in terms >>> of >>> what it can do (even if slowly or whatever - which is not something i >>> intent to >>> argue about given the other reasons). >> >> limited like what? even the fs module that I hugely dislike is in there, >> there is http, dbus and other methods to communicate. > > bare rect, bare image, bare edje, bare image, bare text, bare textblock, bare > emotion, Ahahah. Are you checking reality lately? Other than debug and tests, these are unused for applications. Moreover, if this is the big deal, it is not something big to fix. But it's just not worth because it won't change a thing, it will always be ignored and will bitrot. > no evas map controls, proxy src controls, This is correct, was in the plan by means of properties. Not as done in C as it is unusable by average user, even with the utile helpers. :-( nonetheless you can get the effect with edje, so to some extent (not all) you can get the effects. > animators must be tied to > elm objects only, no animator timeline (animators run over specific time > interval and pass in interval position 0->1), Indeed. But this fits the most common case. And the interval can be calculated. For granted we could expose it once someone needs to use it. > no eet, no efreet, Eet is there by standard JS means, such as the storage functions. As well as with python, it is completely nonsense to expose eet if the platform provides something simpler and more well designed in the context. Python-EFL did well with Pickle for 6 years to prove that. For elev8 we use eet underneath, but not exposed as the JS offers its standard serialization and storage. > no ephysics, Indeed missing, we started to wonder how to nicely expose it, but no time and it was not in the contract... So we focused on what was in there. > ecore-ipc, ecore-audio, ecore-imf, eeze, ephysics, ethumb... These are all nicely encapsulated by elementary or JS standards. For instance, ecore IPC was never interesting given http module. We could use the web sockets to match other, lower level, sockets. But exposing ecore IPC as is brings harm, not good. Again with Python we had 6 years of success showing case this, it's urllib and standard sockets did just fine! I'd you consider Node.js, you get this from elev8 as well. >> the only thing is missing now is the option to create a bare rectangle, >> which is doubtful in real life given that most UI elements are edje >> elements... and they exist in eui right now > > you missed my comment "cannot write efbb". you need raw images, direct map > controls etc. just to begin with... Efbb uses more edje than standard objects. also some of the effects are inside ephysics itself. What I find weird is this kind of arguments that "x is not capable of y". If this was the rationale, terminology couldn't use elementary as it was missing lots of stuff we had to fix and add. Same for Evas, that did not have text grid, it was written to allow terminology to be efficient. Eventually that may be the rationale people use and that's the reason EFL is barely used? We have lots of stuff, but if we miss a single detail they abort the whole analysis and ignore all the good things because of a rarely used item? Sad... Sad ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
