First, before I answer each of your statements below, I'd like to say that your email was rather rude, and it looks like you are biaised. I'm afraid that your answer would open a troll, which is not what I want.
On Sun, Sep 09, 2007 at 04:28:52PM -0700, Michael Jennings 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 know that 'more maintained' isn't a valid concept, but that's what I was told. The activity doesn't represent much either. CodeWarrior has been busy lately, so it could be the reason for his inactivity. Also, CVS commit counts doesn't represent the real status of a project, it actually depends on what they provide and the overall stability. > > 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'm not talking here about what the human eye/brain can perceive. But if you want more details. I was refering to the wiki page about EWL performance. That's one of the main arguments used by the EWL team, and it is true that EWL looks MUCH more performant if we reason by looking at those numbers. But seriously, how many applications use 100K widgets ? What are the "real" performance numbers ? If we compare each and every widget provided by EWL and ETK, which ones are faster? what if we use 10 widgets and not 100K widgets? which toolkit is more performant ? That test was merely a scalability test, that's all it is. I don't plan on use ETK or EWL in such proportions. If I needed to create a chart with hundreds or thousands of buttons and labels then ok, EWL is better, but for a "normal" application, I don't know which one is more performant that the other, and even if EWL is still more performant, if it's a 5% increase in performance, is it worth it to choose EWL over ETK because of performance, if overall, EWL responds less to our demands... That's what I'm talking about, so please, no need to use such an argument. And by the way, quicksort might be faster than bubble sort, but only for large numbers of 'n'. I'm sure that bubble sort is faster on smaller samples. So if you want to use a sorting algorithm, you would see "if you'll work on small samples, use bubble sort, if you plan on sorting huge samples, then use quicksort", so if you know in advance that you'll never sort a list of more than 5 elements, why use quicksort ? And that's EXACTLY what I was asking for from the begining, which one is more suited in this or that situation. > > 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. > When I said equivalent, I meant from an end user point of view, or even from a developer point of view, using this toolkit or the other is the same to you. Don't take it as a personal attack because I compared EWL with ETK. > > 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. > Why such agressivity when you're talking to me? Don't take my sentence out of its context. I never asked anyone to "do my homework" or make decisions for me, or whatever you want to call it. The following sentence is part of this paragraph you just quoted. I'm not asking for one toolkit, I'm not asking raster to make a choice and tell everyone to use this toolkit and not the other, but I'm asking for a non-biaised opinion of someone not belonging to either team to state what are the pros and cons of each one, and which one is more suited for which type of use. > > 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? > Because I'm asking for a point of view coming from someone not belonging to either one of the teams. > > 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? > Did you propose any ? We talked many times about this over #edevelop, and noone suggested or said they could help. The only people interested in those bindings are doing them for ETK, so that "help" I'm refering to will not come from cmarcelo or barbieri, which is already an issue. It's best to concentrate all our efforts in doing one thing. > > 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. > > Nope. > Thanks for trying your best to help the users. > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "I remember the time I knew what happiness was. Let the memory live > again." -- "Memory", from /Cats/ > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
