On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL <cedric.b...@free.fr> wrote:
> On Tue, Jun 25, 2013 at 9:25 AM, David Seikel <onef...@gmail.com> > wrote: > > On Tue, 25 Jun 2013 08:18:01 +0900 Carsten Haitzler (The Rasterman) > > <ras...@rasterman.com> wrote: > >> On Mon, 24 Jun 2013 11:05:00 +0100 Tom Hacohen > >> <tom.haco...@samsung.com> said: > >> > On 22/06/13 02:42, Carsten Haitzler (The Rasterman) wrote: > >> > > On Fri, 21 Jun 2013 11:04:32 +0100 Tom Hacohen > >> > > <tom.haco...@samsung.com> said: > >> > > > >> > >> Hey, > >> > >> > >> > >> I often argue against adding new features (and bugs), libs, > >> > >> widgets, etcetera. > >> > >> > >> > >> I often explain my stance in a per case way. However I > >> > >> stumbled across this nice article which explains where I am > >> > >> coming from. > >> > >> > >> > >> You should probably read it, and hopefully be more conscious > >> > >> about it: > >> > >> http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider > >> > > > >> > > there's a project you'd love and adore. it's called gnome 3. > >> > > remove all possibly removable features and options. :) > >> > > > >> > > yes. features. code.. they cost more than just development. > >> > > it's called maintenance. s a project gets bigger (more code. > >> > > more features) it requires more manpower for maintenance. > >> > > that's life. > >> > > > >> > > >> > You either mistakenly or intentionally got it wrong. I guess me > >> > writing E (while actually meaning EFL + E) was also confusing. > >> > > >> > Obviously if customizability is a main feature of your "product", > >> > those features are essential and should not be dropped. I was > >> > more talking about adding elm widgets just for the sake of it, or > >> > thinking about adding things. > >> > > >> > Also, I don't completely agree with everything he said, but it's > >> > still a good read and I think everyone should take some things > >> > from it. > >> > >> well his article makes a VERY strong point of "never add features.. > >> ever!!!! (unless you absolutely must and have no choice and can > >> justify it)" in fact it makes a point of removing features. it's a > >> very gnome-like stance. > >> > >> yes - elm has too many. we need to refactor much of it to at least > >> internally be the same widget/core just with differing styles. > >> toggle got refactored into check at some point. we could refactor > >> radio and check to merge. gengrid and genlist should become one. > >> etc. u may notice no new widgets have appeared in elm for a while. > > > > I've thought for about a decade, mayby longer, that a widget set > > should be a tiny number of very generic building blocks and some > > inheritance. I called it Not A Widget Set. > > > >> this is also why we've talked about bob... punt off every little > >> customization off into snippets of lua... :) edje itself has also > >> become a massive blob of "features" too... and this is an attempt > >> at finding a better way to manage our feature-pile. > > > > Bob and Lua? Something I've managed to fail to know about? > > Right now only a thought exercice, but you can get info there : > https://phab.enlightenment.org/w/bob/ . Definitely something my LuaJIT experiments will be good for. "A daemon could be in charge of generating the JIT and thus sharing information across processes (Does LuaJIT allow for this?)." If that means that some EFL based C code is generating and compiling Lua code, in response to commands from a socket, then yes. If that also includes running the results in a threaded way with message passing, then also yes (same daemon). I have these working already. Designed to deal with thousands of Lua scripts running at once, and using LuaJIT. I've mentioned this before. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
