On Tuesday, 11 September 2007, at 01:31:52 (+0200), Simon TRENY wrote: > 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!
I'm right there with you. Eterm isn't dead either, though people tend to believe what they want. I've just had other things occupying my time of late. And I don't think anyone ever said Etk was dead. :) The only thing that was said is that EWL has had more commits lately, so from that standpoint, it's more "active." For whatever that's worth. > 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). We could get into a discussion of the relative merits of each approach (less flexibility and more user code required on the Etk side, for example), but I don't think that's germaine to the discussion at hand. > So indeed, Ewl can handle a high number of widgets a lot more > efficiently than Etk. But that's only because it HAS to! That is not a logical argument. That's like saying Oracle handles relational data so efficiently because it has to. You can say, "It's a good thing EWL handles large numbers of widgets efficiently because it tends to have more widgets than a comparable Etk application as a result of EWL design." That is valid. But to say "EWL can handle more widgets more efficiently out of necessity" is to confuse cause and effect. > You will never have more than 300 widgets in an application coded > with Etk. It would be equally fallacious for me to read this and say, "You'll never have more than 300 widgets in an Etk program because it can't handle them!" :) > 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 think the numbers are unfair, feel free to post some of your own. :) But I still contend that, just because you wouldn't sort random long lists of integers thousands of times in a row in the "real world" doesn't mean it's not a good indicator of efficiency. :) > 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... So you found a specific bug in ewl_test with a widget (tree2) which has not been at all optimized and is not even complete. Talk about your biased tests.... Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Men are not subtle. We are obvious. Women know what men want. Men know what men want. What do we want? We want women! That's it. It's the only thing we know for sure." -- Jerry Seinfeld ------------------------------------------------------------------------- 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
