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.

qt is the same - you wrong for qt2 way back. it broke by qt3, then again in qt4 and again in qt5.

motif is stable because it goes nowhere. it gains nothing new. nothing is improved. you could use gtk2 or gtk1 - if your app was written against it and do the same - install the older gtk and compile against it. presto. that's the same situation you have with motif. motif is just gtk1 and it never moved beyond that.

you really are not aware of gtk's history are you? your comment pretty much says it (fyi i don't develop on or for gtk - i have contributed long ago, so i'm neutral on it - but spreading the kind of comments as above is creating fiction likely from someone who never saw the motif version of gimp, and didn't know that it was motif, xt, or "diy" in those days. gimp had tried motif and that was pretty damned bad. xt was worse. qt was not an option as you needed to hunt down binaries of qt for your os as you got no source, and this was a real problem for people running it on solaris, sunos, ultrix, etc. etc. - you could talk openlook - but that was pretty much the same as motif/xt in terms of viability, so the only option left was "diy" and thats how gtk was born).

Actually there is an easy way to do this. an INDIVIDUAL from the project invoices. they act as an independent contractor. They invoice for "support". You don't need a COMPANY to send an invoice and bill someone. An individual can do it. (Companies exist to take advantages of tax and ownership as well as separation of obligations vs the individual). In this case there are no obligations (or shouldn't be).

So now the individual has gained $5000. sure - they must pay tax on it. let's assumed 30% that's $1500. Put the $1500 aside, then give the $3500 to the project - if it has an existing legal non-profit entity. There is no laundering here. You do it in the open. you use fully documented bank transfers. This wouldn't trigger any money-laundering laws I know of. At the end of the tax year, declare the $5000 as "extra income", pay your $1500 in taxes and the project has $3500 now to spend (on a new server, storage, equipment, bug-bounties etc.).

Even better if the project has members who are ex-pats. I know that where I live, only money earned IN the country I am in (Korea) is taxable by Korea, *OR* if i remit money I earn outside Korea back to Korea. If I earn money somewhere else, Korea LEGALLY makes no tax claim over it. As I am not a US citizen... I'm not beholden to the US govt for taxes, regardless of my location, So actually... I can legally earn that money tax-free, so long as it never comes into Korea... so I wouldn't have to put aside $1500 (actually in Korea the tax rate for me is more like 16% - complete flat tax, not 30%). So it's possible and easily done. An invoice is easy to do. I have templates for them...

I think the issue here is that the projects contacted don't have enterprising members who have done contracting/consulting before... etc. etc.