Hello, In the following email, we (Simon and Hisham) will explain why we decided to create Etk. We will mainly organize the email into two parts. The first part will explain what we dont like about Ewl, and the the second part will explain our philosophy.
We have noticed that Ewl lacked (at the time of creating Etk) in the following departments: 1- Menus: Ewl menus do not function like one would expect. This is partially due to an incomplete implementation, and partially to several existing functionality bugs and unexpected behaviour (no mouse / keyboard grabs, improper submenu popups requiring mouse clicks, size calculation problems, and screen location problems; in or off screen). 2- Themeing / Look and Feel: Ewl tends to re-use a lot of parts for several "similar" tasks but eventually ends up looking bad. For example, buttons are used for column headers for trees and for scrollbar drag buttons. Combining this with a lot of scaling and size calculation problems yields bad visual results. The entire look and feel of Ewl applications feels strange and clunky. This has been commented on by the likes of Raster, Vrln, and several other people. A lot of work needs to go on how Ewl applications feel and react to and with the user. 3- Alignment, Clipping and Size Calculation: Labels and buttons are not properly aligned (refer to labels next to checkboxes or radio buttons). Buttons with an empty label have no height no height. Simple things like size calculation and clipping for atomic widgets do not work properly. Resizing any Ewl application is expected to generate undesired clipping and size calculation (look at e_util_eap_edit or ewl_test and notice how resizing the window rigorously causes this). 4. Keyboard Navigation: Ewl has been missing keyboard navigation and general keybindings that are normally expected among toolkits. Until recently this has not been present, we noticed some code about focus / keyboard navigation, but nothing works so far. 5. Fill policy: The fill policy system seems to be too complicated and new behaviour is noticed on a regular basis. This has been shown by the countless times applications like Entropy had to deal with that and simply "tried" until something worked the way it should. 6. Tree Widget: The tree widget needs a serious rewrite. Nathan has recently mentioned fixing it. For now, all the rows are composed of several widgets, including the hidden rows. This means that when you have 3000 items in the tree, you have over 3000 widgets created, and so thousands of Evas_Object's created. Evas was not designed to handle so much objects, even with the widget pool it will not work so well. Ewl's tree widget insists on maintaining the ability to hold any type of widget. We disagree with that concept and would rather have our tree hold only specific types of widgets to allow for extremely optimized performance. 7. Rewrites: Ewl has been re-written and patched up for quite a while. With all those iterations, a lot of extra complication and overhead has been introduced. What is currently being noticed is that entire widgets are being re-written from the ground up, or fixed massively. Since all that effort is being put in, and we already have problems, there's no reason we this cant all start from scratch and become better. In regard to our philosophy and why we decided not to fix Ewl, we will say the following: We will start with a simple example (the author knows himself) which we like to call the chocolate example. If someone owned a chocolate factory and has been producing chocolate for sometime, and one day you tried his chocolate and didnt really like its taste, or sweetness, or feel on your tongue, you shouldnt have to eat that particular brand of chocolate. You shouldnt have to put some more sugar on it, or salt, or anything else to make his chocolate fit your taste. You do have several options though. You can make your own chocolate (based on our own ingedients or his), or simply buy another factory's chocolate. In that same spirit, we believe that just like Nathan (working on Ewl), Dan (working on Ewl), Tilman (working on Euphoria), Chaor (working on Entropy), CodeWarrior (working on Efm), Maxwell (working on an Ewl based media player) or any other developer in the E community, we have the right to say that we dont like this current library or implementation and write a different one. We might write it purely for the sake of learning how to do so. Others before us have learned, why dont we look at their work, their good and bad points, combine it with what we would like to see and how we think things could be done better, and simply write what it is we want to write? We wrote Etk because we wanted to learn more about how to write a toolkit, because we wanted to do things our way, and because we believe we can do a pretty good job at it (and our work proves it so far). If Etk is ever to see the light of day, and it turns out to be a good toolkit, then we would have done nothing but help the E community get a solid stable fast toolkit, and if it were to fail, then we would have tried and learned a lot in the process. We admit to the mistake of not having discussed this in the open. That was our mistake, but it was our choice to make, and it was fine with Raster so we proceeded in that fashion. This does not make it the right thing to do, for perhaps a discussion could have been better, but even with a discussion, we were determined to create a new widget library because our ideas were very far from those used in Ewl. You dont need to support something just because it was started before you, there is no mistake in trying on your own. To conclude, we hope that we have gotten our message through to you and all those who demanded an explanation about Etk and its creation, and also hope that both Etk and Ewl can live and develop in harmony in a positively competitive environment. Best Regards, Simon 'MoOm' Treny Hisham 'CodeWarrior' Mardam Bey ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
