On Sun, 9 Sep 2007 16:28:52 -0700, Michael Jennings <[EMAIL PROTECTED]> wrote :
> On Sunday, 09 September 2007, at 17:40:57 (-0400), > Youness Alaoui wrote: > > > I've been 'bought' by the EWL developers early when I started > > looking at EFL. I heard that EWL is more stable, more maintained, > > better in performance, etc... so I chose EWL. > > EWL might be considered more "active." A simple count of recent CVS > commit e-mails is enough to show that. But "more maintained" isn't > really a valid concept. I'd love to be more active these days, but I'm just too busy with school and other "real" life projects. But it doesn't mean Etk is dead, some devs are doing a really great job on Etk currently! > > > Then I was approached by the ETK developers and I was also 'bought' > > by them into using ETK. saying that ETK is more stable, more > > maintained and the performance is also very good (not better than > > EWL but the difference for a 'normal' application (not using > > thousands of widgets at once) is not noticeable). > > EWL has better performance, period. Just because the human eye/brain > cannot perceive the difference in certain circumstances doesn't > invalidate it, any more than an imperceptable difference in execution > time between a single bubble sort and a single quicksort makes them > equally efficient. I have to rectify this a little. There is a big difference in philosophy between Ewl and Etk. With Ewl, everything is a widget (the cell-objects of a tree-row are widgets) while with Etk, that's absolutely not the case. And this changes *everything*. Let's take a real-case example: let's say you are creating an audio player with a playlist. The playlist uses a tree which has several columns for the artist, the track-number, the title, the length, the album, the user-note, etc. Now let's assume that the user drags-and-drops its entire song collection into the playlist (~10000 songs). With Ewl, it will result in having 10000*number-of-columns widgets (which will be by the way slow as hell because you need to create all these widgets when the user "drops" his collection, and it may also crash your machine because you may run out of memory...). With Etk, there will still be one widget for the tree and... that's all. Memory consumption will also be minimal with Etk (no need to allocate the whole widget structure just for cell-data). So indeed, Ewl can handle a high number of widgets a lot more efficiently than Etk. But that's only because it HAS to! You will never have more than 300 widgets in an application coded with Etk. With Ewl, as soon as you use a tree, the number of widgets will increase heavily (and you won't even be able to control this since it all depends on the user input). So please, when you are doing some benchmarks, compare "real-life" cases, not cases that can only occur on one side. If you want to test it by yourself, just run ewl_test and etk_test, and launch the tests for the tree widgets (tree2 for ewl). When you launch the tree-test of etk_test, it automatically creates 3000 rows. Now, try to set the number of rows in ewl_test to 3000... > > > I see some kind of war between EWL and ETK. Both are toolkits for > > EFL, both are good, both are maintained, etc.. and each group says > > the same thing against the other, but I personally think that both > > of them are equivalent. > > They are equivalent only in the same respects that Gtk+ and Qt are > equivalent (both are widget sets with much the same end-user > functionality), plus one more: both use EFL. Beyond that, they are > not at all equivalent. > > > I think that this war should cease, because the users of EFL are > > lost when it comes to choosing one of the two toolkits, and there is > > nothing official stating which one is to be used. > > Nor will there be. raster has made that clear. Picking EWL or Etk is > really not all that different from picking Gtk+ or Qt or XFCE or Motif > or Tk or Xaw/Xt. What suits your needs best? If you don't know the > answer, do your homework, and/or try as many as you can. But don't > ask someone else to make your decisions for you. If that's what you > want, you're on the wrong project. > > > I think that a wiki page saying something along the lines of : > > - If your application aims to do this and that, then use EWL > > - If your application aims to do that and this, then use ETK > > (showing the pros and cons of each toolkit, and saying which one is > > best suited for your application depending on the use you want it to > > have, etc...) > > As you yourself pointed out, there is much disagreement between the > toolkit authors on those very same pros and cons, so how do you expect > a wiki page to resolve the dilemma? > > > Right now, I'm working with ETK *ONLY* because cmarcelo is writing > > ETK bindings for python and I need to work with python, and I don't > > want to start writing the bindings for EWL from scratch without any > > help. > > Did you ask for any? > > > Can we please finally have an official, objective answer on this > > very important matter, without partiality and without people > > trolling one toolkit with false arguments only for the sake of > > convincing us to choose their own toolkit. I think the best you can do to make your choice is too run both ewl_test and etk_test and try all the widgets, and compare the look-and-feel. Simple widgets will obviously feel the same (a button will feel the same way with the two toolkits), but try more complex widgets. If you don't feel any difference, then look at the code of the test apps, and choose the toolkit with the API that you prefer. Open source is also about having choices. It may sometimes (often?) seem messy, but it's all about freedom. You have several browsers, several audio players, several WM, and... several toolkits. That's just the way it is, and it's not gonna change. People are doing this first because they enjoy to do it. Regards, Simon TRENY <MoOM> > > Nope. > > Michael > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
