and c++ isn't 90's too? :) really? it was invented and used much later than that (as opposed to c)?

yeah. the name is juvenile. just like windows. i mean - how will i find that on altavista? and macintosh. i mean it'll just hide among all the apple varieties of the same name. or what about android? all i'll find is robot porn instead. oh and a galaxy note... note.. gee - i won't find anything outside of a bunch of pictures of paper. or a galaxy gear.. i'll just find cogs all over.

you really know nothing about naming. names evoke ideas and concepts in someones head. a name is inspirational to most. the easier it is to remember (eg is a word they already know) the more easily they attach to it. if they have to remember "xfwm" or "ctwm" ... they will have a far harder time remembering it. "someone told me about this awesome window manager last weekend called f something... bunch of nonsensical letters" but if it's enlightenment.. they remember as the word itself is a unit of knowledge where fvwm is 4 units of knowledge. the word enlightenment will likely be associated with a concept or images, but twm will not.

seemingly a vast swathe of professionals in marketing agree on naming this way in the past, and still do. just SOME examples above.

but who am i kidding. this is slashdot. actual facts cited are irrelevant. trolling with an exaggerated personal opinion is the order of the day.

enjoy your lols. e17 -> e18 took 12 months. it's been about 4 months since e18.

1.6ghz atom. LUXURY! :)

more fun that qml? interesting. why? i'm curious.

i don't remember pulling my rant... ? i'm very much in a habit of "what's done is done". i stick by my words. even to this day.

and yes - i agree. lost my way in hooking up with gnome. i did this because redhat asked me to. it was my job. what i didn't know is that enlightenment and gnome were total polar opposites in goals and design. the hookup was a result of a year+ saying "you need a wm for a desktop" and miguel saying "we don't need no wm for gnome. we can do everything without" and at the end of the year there being a "holy shit. we need a wm now!" and i was the person who could most easily deliver the things needed. so i did. it was my job.

but that process kind of required selling my soul to do so. gnome wanted a wm that dumbly emulated windows 95/98 as closely as possible, would give up all of its extra bits (desktop menus, pagers, wallpaper handling, etc. etc.) and hand over most of its soul and features to gnome and be as bland as possible. metacity was a much better fit for gnome. enlightenment wasn't. the majority of e as disabled for gnome. they just don't fit together. end of story. the idea that you can do a full desktop and not integrate a wm that does just what you need/want was the problem to begin with.

either way - after the divorce, e got e16 out and we started big bang planning for the future, imlib2 (much better imaging support), and then even started messing with opengl to render accelerated graphics with all the fanciness with imlib2 as fallback... and yes - the dot com bubble crashed and everyone - me included had to run for the hills and make a living and we lost a lot of time we used to have... it was some evenings and a weekend then. thus the slowdown. lots of big plans were underway and i was not in the mood for screwing with the plans and work.

these days that work has come to fruition. evas does all the opengl acceleration and has software backed rendering. both are fast. the compositor can use either. it does a lot more besides. e is modular yet a single unified process much like the kernel. we have even widget sets and a full ball of toolkit under it all. it took a while, bet we got there. and now we're reaping the benefits of the work and moving forward. thus e19. :)

that's what we're trying. have the core desktop. all the things you need to make your machine and world function. it's missing bits still and a lot of what is there could be polished more, but the goal is to give you just what you were after as above. any applications after that are optional extras.

git master. if there is a problem... mention it and it gets fixed really fast as long as you find a dev awake and listening on irc. things like:

  hey - if i do x, y and z i get crash blah. here's the backtrace dump e put in ~/.e-crashdump.txt
  hmmm wtf? ... 30 seconds pass
  fix in git. update. :)

options are not for e- but for things like.. you are building an embedded device and you don't use gl.. but you want to cut down a few hundred kb of ram, so using xcb vs xlib is what you want. you can do that, BUT the xcb back-end is 99% complete and you still need xlib if you plan to use opengl due to the binary apis demanding an xlib display handle. you have to have an option. it's not for the wm - it's for the toolkit and special cases. there re lots of such special cases for special purposes. the problem is some smart-butt user thinks it's a great idea to fiddle with every option there with a "ooh i hear xcb is faster" (which is basically is not), and then discovered their fglrx or radeon drivers don't like xcb as the primary display connection and then things crash/hang/don't work... or something like that. this is not the DEFAULT config - it's an option, but it's turned on by people who want to tweak everything - even for packages. it's not bloat - it's features that can be switched for different back-ends, dependencies REMOVED and so on. you really should study up before making assumptions.

that won't help with e or efl. all fonts are drawn the same way. it only affects look. fyi we use efl and e on phones... and not even the mid range ones. talking 200-300mhz things from way back... my standard low-end test box for x86 is a pentium-m@600mhz with 512m ram, no gpu accel at all. e runs decently on that even with software compositing. it's not silky smooth, but it good enough. and as i said.. changing the font mode won't help e - the font glyph is stored as a greymap and renders the same way regardless... but we do care. efl 1.9 now has font compression. we realtime compress fonts with 4bit packed or 4bit RLE if big enough and decompress on the fly - saves memory bandiwdth... and thus gets you speed AND saves memory.

i have no idea why you have so much trouble, but as compiled from source and used every day.. it's really stable and the few hiccups are an easy click away. remember the devs dont use the packages from debian nor even bodhi. we've gotten a lot more rabid about forcing a single universal build of efl and e making it harder and harder for packagers and even users to digress from the default build config. i suspect the issues people see are primarily a result of the insanely flexible build setup that auto-adapted to your dependencies. we've drumped pretty much all of that and you HAVE to --enable/disable things now... and we're getting even stricter on that requiring some hoop jumping before using any configure option we deem to be "not stable/for the masses".

historically every dev uses e right from git master... and that's where the alpha comes from. so it is being dogfooded every single day. generally speaking except for small transitory blips here and there, our unstable "master/trunk/head" is in the same ballpark stable as releases. unlike releases you get fixes for things within sometimes minutes, but mostly hours or a few days. releases (even point releases) take at least days if not a few weeks. :)

e17, 18 and 19 are really just like e16 - just with more bits thrown in. the filemanager is built in. it's not a separate app (like nautilus for example). it's really in the same vein/design just with a vastly more modular codebase and a small mountain of custom written toolkit behind it.

i'm just saying that compiling faster.. or compiling at ALL is a major bonus. as i said - you can't build webkit on a 32bit machine. you can build vastly bigger c projects on those machines easily. literally stopping you from compiling is a MAJOR minus.

and for expanding macros? you don't read much c code. it's macro heaven. :)

and you can do classes rather well in c - multiple inheritance and more. it just depends HOW. but that's ok. i'm never going to convince you that you're taking a fairly extreme position as your mine is made up already.

when gtk was written c was a major advantage over c++ - MAJOR. you could actually compile things. i rememebr back in 1997/98 when gnome was moving to "Corba" and the orb being used was mico (from memory). only people with a big budget for lots of ram (64m+ at the time) could build it... everyone else was in swap land for so long their machines gave out. so redhat compiled mico for people just so the dream of corba could happen (corba was c++). orbit was finally some sanity.

and today, to compile webkit you no longer can do it on a 32bit machine. it literally needs >4gb ram to compile. sorry. c++ has downsides. it also takes the better part of an hour to do so. much bigger c codebases compile with tiny fractions of the ram in tiny fractions of the time. rebuild times and resources to make it happen affect developer productivity a lot. the argument of "c+ is just as good as c in every way and then some" is wrong. there ARE upsides. there ARE downsides. you make your choices intelligently and not just with a "oh c++ is a magic silver bullet to fix all things". the magic bullet attitude is not useful.