| |||||||||||||
Otte: staring into the abyssOtte: staring into the abyssPosted Jul 29, 2012 8:19 UTC (Sun) by bluebugs (subscriber, #71022)In reply to: Otte: staring into the abyss by drag Parent article: Otte: staring into the abyss
Dismissing E17, because it takes time to do think technically right is quite abusive. First of, E17 first needed a modern cleanly designed toolkit. So a massive amount of work was moved into it, to get the lightest, and certainly the most efficient toolkit. With that toolkit, it was possible to write a new terminal in less than one month : http://www.enlightenment.org/p.php?p=about/terminology . Terminal that is faster and lighter than most existing alternative, but still highly themable.
The main reason E17 was never released is that it reached the good enough state and nobody cared to make the last step. In fact most of our community is focusing on the library instead of releasing application. Thanks now, some people are taking care of that last move. But the good enough and the fact that we were fine in our sandbox is the main reason of this slowness.
So don't dismiss technology if you don't know there story and what they can do.
(Log in to post comments)
Otte: staring into the abyss Posted Jul 31, 2012 11:10 UTC (Tue) by ebassi (subscriber, #54855) [Link] First of, E17 first needed a modern cleanly designed toolkit. which is... what, precisely? which one of the bajillion libraries (with runtime loadable modules as separate shared objects), all of them thread-unsafe, with no documentation, and no comments (except for the sporadic 'printf("WAAAAAAA")' ifdeffed out), with a runtime type system based on magic, hardcoded strings and public structs of virtual functions, is the "modern cleanly designed toolkit" you're blabbing about? because I haven't seen anything like that in the Subversion repository (and, really? Subversion?) everything inside the collection of random pieces of junk that is known as "EFL" screams bad design, bad implementation, bad software engineering and release management practices. it's a disgrace that this utter, utter joke of a project has been allowed to go this far, and con lots of money, time, and effort out of users, developers, and companies. have you ever asked yourself why there isn't any documentation on how to create a complex EFL-based application? or, for that matter, why there is no complex EFL-based application at all, except Enlightenment, and now closed sources apps from Samsung and their phones? have you ever wondered why the EFL backend for WebKit is using GLib, libsoup, cairo, gstreamer, and other GNOME technologies? hint: it's because they work, exist, and are designed, developed, and released by competent developers. Enlightenment is a joke, and a bad one at that. the fact that you're using it is utterly inconsequential to its quality, or its development practices. unless you are one of the contributors, to which I would reply that you are a terrible, terrible person, and are directly responsible to two awful weeks of my life in which I tried to work on that horrible code base for my former job, and that I would love to get them back.
Otte: staring into the abyss Posted Jul 31, 2012 14:44 UTC (Tue) by bluebugs (subscriber, #71022) [Link]
Wondering here how you did spend your two weeks, certainly not looking at the right place. Nice troll about Subversion by the way, but that one I will let it to someone else. Let's start just by fact.
Documentation : http://web.enlightenment.org/p.php?p=docs&l=en . As you can see, updated daily and available online easily.
"Bad implementation, bad design, bad software engineering", man you are really shooting yourself in the foot here. Enlightenment is faster, lighter and yet more powerful than any thing you can compare it to. Writing a terminal emulator from scratch took 1 month as a pet project, and beat hands down every other terminal emulator in speed and effect (memory when comparing it with tabless emulator). If that's what you get by bad implementation, bad design and bad software engineering, every one should start doing bad stuff that would help !
As for big application, the main reason is that nobody in the Enlightenment community were interested by replacing existing application. We were having fun in our sandbox, didn't bother doing marketing and didn't try to get more users/developers. You may have notice that we do have around 30 people working permanently on all EFL libraries (when GTK only get one), that's because people in our communities have fun with improving and tunning this libraries. But things are evolving. That's why we now have release and are starting communicating. That's why we do start writing more application. Because we also thing that it's a time that require us to speak. Let see if in two years we don't get big applications written in EFL.
About WebKit, well it was a GTK port that was moved to EFL (That does prove my point to a previous thread where moving to EFL is doable), so obviously not all technology get replaced. And what GNOME technologies are you speaking about ? Cairo, Gstreamer ? Are you sure they where created by and for GNOME ? Are you sure you can be so proud of their current state ?
As for the fact, we did have a Cairo backend for Evas, we scratched it because it was to slow and never was close to the performance we had with our own software backend. The only reason we need it is for vector graphics, and we are close to have an alternative that is already way faster. And Gstreamer, on any PC, VideoLan give better result, it's more stable and use less resource. We do use Gstreamer, because that's the only choice we have in the embedded world today, but frankly on a desktop go with VideoLan !
By reading your comment, I guess you were forced to look at EFL and took it as a personal attack on your own work. Did your management ask you to dumb all your past work because it didn't perform correctly ? Seriously you go on personal attack here, and it really look to me like EFL did beat the code you did write in the past without giving you a little chance to catch-up. I feel sorry for you, but if one day you calm down and really want to learn about how a modern toolkit should be designed and why, I will be happy to have a drink and discuss that matter with you.
|
|||||||||||||