Re: [E-devel] Starting programming in EFL
Am Sun, 9 Sep 2007 23:49:01 -0400 schrieb Youness Alaoui: I've proposed that common parts should be made as another library, so more things are shared... as they already share evas (base graphics) and edje (theme), I think that layout could be split in a libelayout, doing hbox, vbox and tabular, with all required packing options (expand, fill, ...), we could use this in other apps, like rage. But both teams said they're completely different in this area and would need a deep refactor to adapt to this... I proposed to do that myself, but no time yet :-P Anyway, sharing these basic components could (in theory!) lead to these toolkits unifying someday, but someone need to do the work others don't want to do (like this libelayout). Well, I agree on what you're saying, and I've thought about it too, but slightly different. I was thinking that E, just like KDE and Gnome, should have its own toolkit, and 'etk' answers that by being 'enlightenment toolkit' (I'm talking here about the key word toolkit). So if we compare the words Enlightenment Toolkit then ETK is a toolkit... while EWL, Enlightenement Widget Library is more of a library providing widgets (which is also known as a 'toolkit' but it doesn't have the 'toolkit' keyword in it). So I thought that maybe ETK should provide a simple to use API, wrapping EWL, where EWL would be as customizable as possible. If I understood correctly, the main difference in ETK and EWL is that they have different views on how the API should be and the widgets should look, so if ETK uses EWL in the background, provides the API it wants, and customizes the EWL widgets to look the way ETK developers want it to look, then the choice would be easier : use ETK if you want a high level toolkit, or use EWL if you want a set of widgets that you want to use and customize the way you want them to be. ETK being a simple wrapper to EWL would avoid code duplication, would centralize the efforts, and would help the users choose their API more easily.. instead of saying : you have two toolkits, choose one, one could say EWL provides you with widgets, and ETK wraps it into a higher level API. That would be awesome, but I'm guessing this idea will get some people angry... not sure what others think though...? You may search in the archive some month ago. I had the same question and there were the same answers. But my problem was more the theme double work than the API. Currently you need to do many theme work if you like to have a desktop in one style (E, EWL, ETK, and not counting all that Esmart_Container and custom Evas_Smart using apllications). All the ease of theme creating with Edje is useless if you need to theme most widgets at least three times. I understand that EWL or ETK developers spend to much work in _their_ toolkit to throw part of it away. If I were an ETK developer I would be pissed off by ideas like: ETK should be an EWL wrapper and not more. But I think it should be possible to unify some things between at least ETK and EWL (perhaps E itself). I tried both tester applications, looked at the API, looked into the source and wrapped some (small) parts of it in eflpp (C++ wrapper) (not yet commited). I understand the different thinking of ETK and EWL developers, but from the end users (not application developers) point of view ETK and EWL are pretty the same. The difference between GTK and QT is much much bigger. But theme creators are nerved because they need to create many themes. And users are nerved because widgets look perhaps only 95% the same on their desktop. Application developers have the choose about the toolkit to use, but application users don't have this choose! Currently developers, users and theme creators are most the same people. But this will hopefully change in future. Most themes will always be uncomplete because there's only ETK or EWL included (what the author likes more). So users need to become theme creators to have a consistent looking desktop. You put more work into themes with the current way. How mamy _complete_ themes with consistency about all apps do you know? I know only the default theme. Perhaps there's another theme that I don't know. So if ETK, EWL (and perhaps E) would use a unified theme for about 80% of the widgets, this would be marvelously. I could write some words about the differences I found between ETK and EWL. But I don't like to do that. Please concentrate on the similarities. If only EWL and ETK developers would be open to that idea... regards Andreas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2007-09-10 07:02:43 -0700
Build log for Enlightenment DR 0.17 on 2007-09-10 07:02:43 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: engage http://download.enlightenment.org/tests/logs/engage.log entropy http://download.enlightenment.org/tests/logs/entropy.log evfs http://download.enlightenment.org/tests/logs/evfs.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, entrance, envision, epdf, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Sunday, 09 September 2007, at 23:52:14 (-0400), Youness Alaoui wrote: At least an answer, althought I'm not sure about your arguments, I'd like to see some ETK developer give his point of view. But before you said you wanted opinions from people who weren't on either team. So make up your mind on what you want. :P Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- The notion that something as complex and thermodynamically improbable as life could form out of a bit of ooze is about as believable as a jet airliner being assembled during a hurricane in a junkyard. -- Fred Hoyle (quoted by Sonia Shah) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Sunday, 09 September 2007, at 23:49:47 (-0400), Youness Alaoui wrote: 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. My e-mail was not rude. What is rude is to presume to tell the authors of other projects what they should do with their own work. And everyone is biased. Anyone who has given the issue enough logical, considered thought to form an opinion on the situation is biased, and anyone who has not has no business giving an opinion to begin with. I presented the situation as I see it, fairly and rationally. What's important is not that I have an opinion, but rather than I have no vested interest in either project. I am not an author of either library nor of any project that depends on or is driven by either library. The activity doesn't represent much either. CodeWarrior has been busy lately, so it could be the reason for his inactivity. There's the keyword: inactivity. The reason is immaterial: I referred only to activity or the lack thereof. The author(s) being otherwise occupied is the very definition of inactive. (See also: Eterm. Just because I have very good reasons for not being able to work on it lately doesn't make it any more active.) Also, CVS commit counts doesn't represent the real status of a project, it actually depends on what they provide and the overall stability. Clearly that doesn't stop people from telling you it's a reason to use one library over another, since that's exactly what you claim they did. 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. I know exactly what you were talking about. I saw the numbers when they were first posted. But seriously, how many applications use 100K widgets ? That's a silly question. How many applications sort millions of pieces of data? Any that want to. How many applications use 100,000 widgets? Any that want to. What are the real performance numbers ? There's no such thing. Even beginning computer science courses cover the basic futility of benchmarking, the need for mathematical representations of efficiency and complexity (like Big O notation), etc. I shouldn't need to sit here and explain that. 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 ? EWL. That test was merely a scalability test, that's all it is. That's simply false. Because computers are so fast, we often have to use large, even unrealistic quantities of data to generate numerically significant differences in measurements when comparing algorithms and implementations. Run make perf in libast sometime; some routines have to run through millions of iterations just to get numerically significant runtimes. Scalability indicates efficiency. Single-pass performance tests are not statistically valid because there are too many outside variables. But when we scale things up, those variations become less significant and the results more valid. It's the same principle. If EWL is more efficient with 100,000 widgets, it's because it's more efficient with 1 or 2 widgets. 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, Of course you do. 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... What does that mean? No one has said anything about responding to demands until now. That doesn't even make any sense in the context of this conversation. That's what I'm talking about, so please, no need to use such an argument. That's the problem. You don't seem to know what you're talking about, or at least about the issues surrounding it. No offense intended; you just don't seem to grasp the concepts at hand. 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. This statement seems to illustrate my point quite effectively. You could not be more mistaken. 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. And I'm saying you're wrong. :) Don't take it as a personal attack because I compared EWL with ETK. I have nothing personal invested in it. I don't take anything
Re: [E-devel] Starting programming in EFL
On Sunday, 09 September 2007, at 23:49:01 (-0400), Youness Alaoui wrote: Well, I agree on what you're saying, and I've thought about it too, but slightly different. I was thinking that E, just like KDE and Gnome, should have its own toolkit, and 'etk' answers that by being 'enlightenment toolkit' (I'm talking here about the key word toolkit). So if we compare the words Enlightenment Toolkit then ETK is a toolkit... while EWL, Enlightenement Widget Library is more of a library providing widgets (which is also known as a 'toolkit' but it doesn't have the 'toolkit' keyword in it). I really sincerely hope you're kidding. This kind of thinking quite simply defies all logic and reason. ETK being a simple wrapper to EWL would avoid code duplication, would centralize the efforts, and would help the users choose their API more easily.. instead of saying : you have two toolkits, choose one, one could say EWL provides you with widgets, and ETK wraps it into a higher level API. That would be awesome, but I'm guessing this idea will get some people angry... not sure what others think though...? I think those who are not authors of the aforementioned toolkits need to BUTT THE HELL OUT and stop trying to make decisions for projects that don't involve you, that you don't understand, and that you have no business interfering with. If you want a widget library to wrap EWL, write your own. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- To live on as we have is to leave behind joy, and love, and companionship, because we know it to be transitory, of the moment. We know it will turn to ash.-- Lorien, Babylon Five - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
- Forwarded message from Youness Alaoui [EMAIL PROTECTED] - From: Youness Alaoui [EMAIL PROTECTED] To: Nathan Ingersoll [EMAIL PROTECTED] Subject: Re: [E-devel] Starting programming in EFL Exactly, I don't care much about the performance (as long as it's not affecting usability). I was just answering Michael that his EWL has better performance, period. is a bad argument since it is unproven facts. And I don't care about those 'facts' since ETK devels could say the same thing, and I was pointing out that the EWL_Performance page was not very significant if we don't plan to use thousands of widgets. On Mon, Sep 10, 2007 at 09:39:49AM -0500, Nathan Ingersoll wrote: On 9/9/07, Youness Alaoui [EMAIL PROTECTED] wrote: 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. It is? I don't recall ever telling someone that performance is the main reason to use EWL. I'm fairly certain I told you to take those numbers as a way we are testing widget scalabiity. The other toolkits are there for a frame of reference, since it's hard to know what is good or bad without a frame of reference. Maybe not you, but I've heard others.. 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 ? Faster doing what? Setup, layout, repainting, scrolling, etc, etc? What theme are you using? How many different images or fonts are used? What features are you using for those particular widgets? There are many things you can test for performance. I took the time to test and optimize one case, but I have found that test useful for improving other areas as well. I barely have time to work on EWL code let alone test and compare every single aspect of various toolkits. Yep, that's exactly what I had in mind, being able to see the time (and memory) used for each widget, for each operation, creating it, configuring, repaiting, etc.. I might do it myself, I'm not asking you to do it, I'm just saying that unless documents like that are provided, I don't think that saying X is more performant than Y is a valid statement. 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. Why are you so concerned about performance for such a small case? Unless the toolkit is causing blocking points, busy loops, or doing something else stupid, there will most likely be very little difference. 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 unless you are repeatedly sorting this small data set, how is it of any interest? The difference is going to be barely measurable on a modern system. Exactly, I don't care much about the performance (as long as it's not affecting usability). I was just answering Michael that his EWL has better performance, period. is a bad argument since it is unproven facts. And I don't care about those 'facts' since ETK devels could say the same thing, and I was pointing out that the EWL_Performance page was not very significant if we don't plan to use thousands of widgets. Thanks for answering! KaKaRoTo - End forwarded message - - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Mon, Sep 10, 2007 at 01:10:11PM -0400, Michael Jennings wrote: On Sunday, 09 September 2007, at 23:49:01 (-0400), Youness Alaoui wrote: Well, I agree on what you're saying, and I've thought about it too, but slightly different. I was thinking that E, just like KDE and Gnome, should have its own toolkit, and 'etk' answers that by being 'enlightenment toolkit' (I'm talking here about the key word toolkit). So if we compare the words Enlightenment Toolkit then ETK is a toolkit... while EWL, Enlightenement Widget Library is more of a library providing widgets (which is also known as a 'toolkit' but it doesn't have the 'toolkit' keyword in it). I really sincerely hope you're kidding. This kind of thinking quite simply defies all logic and reason. It certainly depends, seeing how your logic work, I understand how you can't figure out how my logic works. ETK being a simple wrapper to EWL would avoid code duplication, would centralize the efforts, and would help the users choose their API more easily.. instead of saying : you have two toolkits, choose one, one could say EWL provides you with widgets, and ETK wraps it into a higher level API. That would be awesome, but I'm guessing this idea will get some people angry... not sure what others think though...? I think those who are not authors of the aforementioned toolkits need to BUTT THE HELL OUT and stop trying to make decisions for projects that don't involve you, that you don't understand, and that you have no business interfering with. If you want a widget library to wrap EWL, write your own. Michael Oh right, you're completely right.. and since you're not an author of those libs, as you said yourself, then why don't you just BUTT THE HELL OUT and stop polluting this thread. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
no comment.. if you can't even read and understand a sentence without me explaining every word to you, I don't see why I'm wasting my time with you... On Mon, Sep 10, 2007 at 01:53:17PM -0400, Michael Jennings wrote: On Sunday, 09 September 2007, at 23:52:14 (-0400), Youness Alaoui wrote: At least an answer, althought I'm not sure about your arguments, I'd like to see some ETK developer give his point of view. But before you said you wanted opinions from people who weren't on either team. So make up your mind on what you want. :P Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- The notion that something as complex and thermodynamically improbable as life could form out of a bit of ooze is about as believable as a jet airliner being assembled during a hurricane in a junkyard. -- Fred Hoyle (quoted by Sonia Shah) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net 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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Monday, 10 September 2007, at 16:40:13 (-0400), Youness Alaoui wrote: Well, I agree on what you're saying, and I've thought about it too, but slightly different. I was thinking that E, just like KDE and Gnome, should have its own toolkit, and 'etk' answers that by being 'enlightenment toolkit' (I'm talking here about the key word toolkit). So if we compare the words Enlightenment Toolkit then ETK is a toolkit... while EWL, Enlightenement Widget Library is more of a library providing widgets (which is also known as a 'toolkit' but it doesn't have the 'toolkit' keyword in it). I really sincerely hope you're kidding. This kind of thinking quite simply defies all logic and reason. It certainly depends, seeing how your logic work, I understand how you can't figure out how my logic works. Sorry, but there is no logic in saying E should have its own toolkit, and it should be ETK because it has the 'TK' for 'toolkit' in it and EWL doesn't. None whatsoever. Naming is a non-issue and has no bearing on anything of relevance whatsoever. Oh right, you're completely right.. and since you're not an author of those libs, as you said yourself, then why don't you just BUTT THE HELL OUT and stop polluting this thread. Look. You're telling 2 projects you have nothing to do with what they should be doing. Surely you don't think that's acceptable If the authors of EWL and Etk had wanted them to work the way you describe, they'd have designed them that way from the beginning. Obviously, they didn't. So what's the point of even making such suggestions? You're accomplishing nothing whatsoever. 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 wish you'd look at me that way, your beautiful eyes looking deep into mine, telling me more than any words could say. But you don't even know I'm alive. Baby, to you all I am is the invisible man. -- 98 Degrees - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Monday, 10 September 2007, at 16:42:25 (-0400), Youness Alaoui wrote: At least an answer, althought I'm not sure about your arguments, I'd like to see some ETK developer give his point of view. no comment.. if you can't even read and understand a sentence without me explaining every word to you, I don't see why I'm wasting my time with you... Feel free to point out the part I failed to read and/or understand. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- She'd still say, 'I love you' if I asked, but she never volunteers. Somehow what she never says means more than all the other words I hear. -- BlackHawk, I Sure Can Smell the Rain - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Monday, 10 September 2007, at 16:39:20 (-0400), Youness Alaoui wrote: Exactly, I don't care much about the performance (as long as it's not affecting usability). I was just answering Michael that his EWL has better performance, period. is a bad argument since it is unproven facts. And I don't care about those 'facts' since ETK devels could say the same thing, and I was pointing out that the EWL_Performance page was not very significant if we don't plan to use thousands of widgets. And I was pointing out that you are mistaken in that belief. Did you not understand my explanation, or are you choosing to ignore it because you take offense to how I present it? Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- What can I do to make you mine? Falling so hard, so fast this time. What did I say? What did you do? How did I fall in love with you? -- Backstreet Boys, How Did I Fall in Love with You - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Mon, Sep 10, 2007 at 05:00:12PM -0400, Michael Jennings wrote: On Monday, 10 September 2007, at 16:39:20 (-0400), Youness Alaoui wrote: Exactly, I don't care much about the performance (as long as it's not affecting usability). I was just answering Michael that his EWL has better performance, period. is a bad argument since it is unproven facts. And I don't care about those 'facts' since ETK devels could say the same thing, and I was pointing out that the EWL_Performance page was not very significant if we don't plan to use thousands of widgets. And I was pointing out that you are mistaken in that belief. Did you not understand my explanation, or are you choosing to ignore it because you take offense to how I present it? Michael And did you not read my example of the sorting algorithm or did you ignore it because you take offence to how I present it? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Monday, 10 September 2007, at 16:59:55 (-0400),
Youness Alaoui wrote:
maybe you should look up 'rude' in the dictionary.. try the
synonyms, there must be something with stronger value than 'rude'.
http://nizkor.org/features/fallacies/ad-hominem.html
And who said I'm here to tell anyone what to do with their own
projects,
Allow me to quote:
So I thought that maybe ETK should provide a simple to use API,
wrapping EWL, where EWL would be as customizable as possible.
And again:
so if ETK uses EWL in the background, provides the API it wants,
and customizes the EWL widgets to look the way ETK developers want
it to look, then the choice would be easier a high level toolkit,
or use EWL if you want a set of widgets that you want to use and
customize the way you want them to be.
And again:
ETK being a simple wrapper to EWL would avoid code duplication,
would centralize the efforts, and would help the users choose
their API more easily. ... That would be awesome...
all the above is just LOL, I can't beleive you wrote that while
being seriously.. I wonder how silly one can be...
I see. So you're offended, and now you're lashing out instead of
actually paying attention.
ok, you might be right on this little thing, although you're far
from being completely right. Scalability is helpful only if the
performance is perfectly linear. if not, then it's useless.
That is not a mathematically valid statement. Whether it's linear
(O(n)), exponential (O(n^2)), or something in between doesn't really
change the fact that scalability indicates efficiency.
What does that mean? No one has said anything about responding
to demands until now. That doesn't even make any sense in the
context of this conversation.
well you should maybe read my mails before asking because clearly
that's what I've been talking about since the first email.
I don't think you're using the right word. What demands, and who's
making them? And in what way is EWL less responsive, or Etk more
responsive, to those demands?
You're pathetic...
And you still haven't said anything to indicate that you understand
the concepts I mentioned, let alone refute any of them. See previous
URL.
Good, it proves that I'm right, because so far, I don't think you
ever said something useful and true...
http://nizkor.org/features/fallacies/guilt-by-association.html
oh sorry for not looking up the word correctly in the dictionary.
You're blunt, not agreessive? what's the big difference.
blunt
adj 3: characterized by directness in manner or speech; without
subtlety or evasion;
{frank}, {free-spoken}, {outspoken}, {plainspoken},
{point-blank},
{straight-from-the-shoulder}]
4: devoid of any qualifications or disguise or adornment;
aggressive
adj 4: characteristic of an enemy or one eager to fight;
In any case, blunt or agressive, or rude or whatever you want to
call it, you should just learn how to shut up, because obviously,
you'll never learn how to talk (or write).
I see.
Yeah, forgot you're perfect and would never do such a thing. Reread
my post, it was out of context.
Claiming something does not make it so. Feel free to point out
precisely what I quoted out of context, along with the context which
was missing, and I'll be happy to address it. Absent that, I see
nothing quoted out of context nor any reasonable possibility for doing
so.
where? which point of view? I didn't get your point of view, I only
got use EWL, it's better, period.
I said nothing of the sort. If that's all you got from everything
I've written, there would appear to be a language barrier of some
kind.
Just to let you know mister who understand always everything, that
in this case, the users I was referring to are myself and my team,
users, in the sense of users of the library, not the end user
clicking the buttons... a user for an application developer is the
Joe Guy using his application, the users of a library are the
application developers using the library.
I would point out that end users clicking the buttons are *using* the
library. So that's how I interpreted your statement. Thanks for
clarifying.
I don't need to comment on your other stupid comments, that would
just be a waste of time.
I'm sure it would.
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.
Re: [E-devel] Starting programming in EFL
On Monday, 10 September 2007, at 17:02:44 (-0400), Youness Alaoui wrote: And did you not read my example of the sorting algorithm or did you ignore it because you take offence to how I present it? I don't take offense at your examples. I don't even take offense at your excessive ad hominem attacks; to take offense, I would have to concede that you have the standing from which to make them. I have not done so. As I said, your example was simply incorrect. Quicksort is O(n log n) in the average case and O(n^2) in the worst case. Bubble sort is always O(n^2). So, barring the inherent random variances in a small sample set, bubble sort will not be faster than quicksort, even for small data sets. Feel free to consult http://en.wikipedia.org/wiki/Sorting_algorithm for the particulars. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- A lot of times, men do things they don't want to do so the woman they're going out with will do things *they* don't want to do. -- Tim Allen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Mon, 10 Sep 2007 17:35:01 -0400 Michael Jennings [EMAIL PROTECTED] wrote: On Monday, 10 September 2007, at 17:02:44 (-0400), Youness Alaoui wrote: And did you not read my example of the sorting algorithm or did you ignore it because you take offence to how I present it? I don't take offense at your examples. I don't even take offense at your excessive ad hominem attacks; to take offense, I would have to concede that you have the standing from which to make them. I have not done so. As I said, your example was simply incorrect. Quicksort is O(n log n) in the average case and O(n^2) in the worst case. Bubble sort is always O(n^2). So, barring the inherent random variances in a small sample set, bubble sort will not be faster than quicksort, even for small data sets. Feel free to consult http://en.wikipedia.org/wiki/Sorting_algorithm for the particulars. Michael While it's true that bubble sort isn't ever going to be faster, that's not just because it's always O(n^2). Insertion sort is also O(n^2), but it does outperform quicksort on small data sets (under 10 elements or so)... highly optimized sorting algorithms often use quicksort to sort large data sets, but switch to insertion sort once the partitions drop below a certain size, since it's faster. See http://en.wikipedia.org/wiki/Insertion_sort for details. Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Monday, 10 September 2007, at 17:17:21 (-0500), Jesse Luehrs wrote: While it's true that bubble sort isn't ever going to be faster, that's not just because it's always O(n^2). Insertion sort is also O(n^2), but it does outperform quicksort on small data sets (under 10 elements or so)... highly optimized sorting algorithms often use quicksort to sort large data sets, but switch to insertion sort once the partitions drop below a certain size, since it's faster. See http://en.wikipedia.org/wiki/Insertion_sort for details. True. I had forgotten that tidbit. Thanks! :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Sometimes I give myself the creeps. Sometimes my mind plays tricks on me. It all keeps adding up; I think I'm cracking up. Am I just paranoid? Am I just stoned?-- Green Day, Basket Case - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
Oh dear me. Look what this has become while i've not been looking. (i'm just going to reply to the whole thread tree here and ignore the sniping bits - hey kids - back to your seats!). ETK vs. EWL - it can be summed up with: I may not agree with what you say, but I will defend your right to say it to the death.. We are not going to kill one off. They are like Apple vs. Orange juice. ETK and EWL developers were working together at one point - but basically had a core disagreement in philosophy. They have agreed to disagree. Unlike GTK vs. Qt the cost is much lower. They share big amounts of core via Ecore, Evas, Edje etc. I realise that saying this one is official will alienate the other group. Both groups are important to E in general. Both have made invaluable contributions and continue to help. At some point (E18/19) I will need to use one or the other for E itself - but do NOT take this as official endorsement - it will be based on whichever I feel more comfortable with. Those familiar and happy with GTK's API might prefer ETK. Others may prefer EWL. It's a matter of choosing if you like Apple or Orange juice. Both are juices. Both quench your thirst. Both are sweet. (And no nit picking on the analogy. You get the idea!!!). Which should you choose? Well - try both. Which one do you like best? No one can make that decision for you. You either try both - or just make a leap of faith. Both teams will promote their work - and good for them. take away with that only what they can tell you factually about their code. Now everyone - back to your benches and take 5. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
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 (~1 songs). With Ewl, it will result in having 1*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
Re: [E-devel] Starting programming in EFL
On Tuesday, 11 September 2007, at 08:23:58 (+0900), Carsten Haitzler wrote: Which should you choose? Well - try both. Which one do you like best? No one can make that decision for you. That answer has already been given multiple times (by me and others) and rejected multiple times as insufficient. I'm not sure what's to be accomplished by saying the same thing yet again. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- When the toast is burned and all the milk has turned and Captain Crunch is waving farewell, when the Big One finds you, may this song remind you that they don't serve breakfast in Hell. -- Newsboys, Breakfast - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] tools that update ChangeLog files
On Sat, 1 Sep 2007 16:31:53 +0200 (CEST) Vincent Torri [EMAIL PROTECTED] babbled: On Sat, 1 Sep 2007, Gustavo Sverzut Barbieri wrote: On 8/30/07, Vincent Torri [EMAIL PROTECTED] wrote: Hey, currently, there is no trace of the commits in the ChangeLog file. We can only look at them through viewvc, which is a pain (cia is not better and does not allow to see all of them, afaik) I dislike changelog as a CVS history clone, it should be used for major things done. I think that NEWS is more for major stuff than ChangeLog. But it's a matter of taste, i guess. As I said, I prefer having a changelog rather than having to look at the commits through cvsweb or whatever viewer of cvs rep. all cvs commits mails are in my cvs commits mailbox - that works well for me... :) somehow automatic changes to the changelog from cvs i don't see as that useful. right now changelog isn't used because nothing is at 1.0 as of 1.0 i will keep changes there as important feature additions, removals and compatibility changes as well as bug fixes. BTW, I'm running a GIT version of E libs at staff.get-e.org and it works great, log is easier to see using git and gitweb is way more responsive! It's not official yet, but if you like: http://staff.get-e.org/ great :) Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas smart-objects future plans?
On Tue, 4 Sep 2007 13:23:51 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Sat, 25 Aug 2007 12:41:02 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Tue, 21 Aug 2007 00:58:58 +0200 Simon TRENY [EMAIL PROTECTED] babbled: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). mmm - basically those can probbably be handled by intercepts or events. color_set, clip_set/unset should just work as expected. i just can't see any other really good reason to not have them do the obvious - same with show and hide. I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. yup. so instead of creating a clip object and add it to the smart - then clip all smart members to the clip to handle color_set - is tedious. I'm willing to try to implement those things in Evas, but first I'd like to be sure of the behaviour to respect: - A member-object should be really visible only if its parent is visible and if it is set as visible (evas_object_visible_get() == 1). It would remove the need for show() and hide() correct. the parent smart object visibility should be a master control for all children. hidden children will never be visible - shown children are visible ONLY if the parent is visible too. - A member-object should be clipped by the intersection of its clipper and of its parent's clipper. It would remove the need for clip_set() and clip_unset() correct. same with clip colors. a smart object's parent color should multiple all child objects like a clip object's color multiplies all clipees (objects clipped by the clip object). basically the smart object is an implicit parent clip etc. proxy for children. - The member-objects' color should be automatically multiplied by its parent's color at rendering (-- no more need for color_set()). correct. Actually, I'm not sure about this last point. What if the user would absolutely want to have a member-object always green for example, regardless to the color of its parent? I can see a use for this: in estickies, the window is semi-transparent while the text is opaque, and yet, the text is a member-object of the window. no - always. parents should control children. fading out a button that contains an icon won't work unless you color multiply always. Are you ok with this? Do you have any other requirements for the smart-objects? currently- not really. i know this thread has gone on a bit - but the arguments for show/hide etc. are there, but can be done by events (on a hide - stop all animation - or even destroy child objects to save memory/space and on show create them again - but do via an intercept or event callback). as a fist step - lets not remove, but if show/hide etc. are NULL - then apply the above default behavior. I agree with this. I'll try to look at this in the next few days. Btw, is there any plan to add the ability to render a smart-object into a buffer with Evas? It would solve some problems with clip/color-set with alpha != 255 (for example, if two member-objects are overlapping), and it could also be used to improve performances for widgets that use scrolling (list, iconbox, textblock, ...). actually i will eventually add that as a clip option. clip as now where each object gets clipped individually - OR later, when option is there, render first to buffer without color modifications (but with clipping) THEN modify as a group (this will also imply that stacking will become continuous so if you have non-clipped objects between clipped ones in the stacking layers - then this won't work). but this is a future plan and smart objects could use the same back-end or idea. buffers slow down rendering as we need to render to buffer first, then take that - also if we keep buffers around it costs memory, so nothing comes for free. Simon Regards, Simon TRENY MoOM - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list
Re: [E-devel] Starting programming in EFL
Hi Carsten! I bow before your words of wisdom, lol. Everything you said makes sense and that's what I understood from the start (kind of). I like your analogy of apple and orange juice :p As I said many times, I never asked for an official toolkit (although I presented that idea, as part of a 'let my brain go free' theory about ETK wrapping EWL in order to have the API and lookfeel it wants without duplicating code efforts). I was merely asking for an official (non biased by either group members) position on the pros and cons of each toolkit. the EWL guys will tell me that EWL is better, the ETK guys will tell me ETK is better, but both teams use their own way of presenting information, which may or may not be completely true. Maybe I should have said the opinion of someone who investigated both projects instead. By opininon I'm not requesting a this one is better, but only requesting this one has these pros and cons, and this other one has these pros and cons, maybe concluded by I chose x because I needed this and I felt more confortable with its API for example, which does not mean that *I* would choose the same thing. To go back to your apple vs. juice analogy, one could say : - apple juice is sweeter but has more calories - orange juice is more healthy and has vitamin C I chose apple juice because I like sweets. In other words, pros and cons, real facts, and in the end, based on that 'comparison table', one could choose what best fits for his application. Having the choice between two toolkits is good (apart from the code duplication involved), as long as it doesn't take 1 week of code reading and testing and proof of concept writing for someone to finally decide which one to choose. Being able to choose what you like best would be easier with such a listing. Again, I don't vote for a single toolkit, I just vote for an 'official/non-official' expertise on the two toolkits, providing the users (of the library) with valuable information to help them decide on which toolkit to choose. Thanks for your time. KaKaRoTo On Tue, Sep 11, 2007 at 08:23:58AM +0900, Carsten Haitzler wrote: Oh dear me. Look what this has become while i've not been looking. (i'm just going to reply to the whole thread tree here and ignore the sniping bits - hey kids - back to your seats!). ETK vs. EWL - it can be summed up with: I may not agree with what you say, but I will defend your right to say it to the death.. We are not going to kill one off. They are like Apple vs. Orange juice. ETK and EWL developers were working together at one point - but basically had a core disagreement in philosophy. They have agreed to disagree. Unlike GTK vs. Qt the cost is much lower. They share big amounts of core via Ecore, Evas, Edje etc. I realise that saying this one is official will alienate the other group. Both groups are important to E in general. Both have made invaluable contributions and continue to help. At some point (E18/19) I will need to use one or the other for E itself - but do NOT take this as official endorsement - it will be based on whichever I feel more comfortable with. Those familiar and happy with GTK's API might prefer ETK. Others may prefer EWL. It's a matter of choosing if you like Apple or Orange juice. Both are juices. Both quench your thirst. Both are sweet. (And no nit picking on the analogy. You get the idea!!!). Which should you choose? Well - try both. Which one do you like best? No one can make that decision for you. You either try both - or just make a leap of faith. Both teams will promote their work - and good for them. take away with that only what they can tell you factually about their code. Now everyone - back to your benches and take 5. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net 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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
- Forwarded message from Youness Alaoui [EMAIL PROTECTED] - From: Youness Alaoui [EMAIL PROTECTED] To: Simon TRENY [EMAIL PROTECTED] Subject: Re: [E-devel] Starting programming in EFL On Tue, Sep 11, 2007 at 01:31:52AM +0200, Simon TRENY wrote: On Sun, 9 Sep 2007 16:28:52 -0700, Michael Jennings [EMAIL PROTECTED] wrote : [...] 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 (~1 songs). With Ewl, it will result in having 1*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... Hi, Thanks for this explanation, it's helpful to have detailed info on such use cases. [...] 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. Yes, I tried them both, that's the first thing that made me like etk more than ewl, basically because of stability, since the ewl_test kept crashing for many of the widgets, and it had a huge amount of glitches. But also the look and feel seemed to be better. Simple example is the paned window, I like the animated arrows that ewl doesn't have. About the API, I know the ETK API now, but I don't know much about the EWL API yet, I'll probably look into it and see how it goes.. Thanks again for this helpful info. KaKaRoTo - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
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 (~1 songs). With Ewl, it will result in having 1*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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On Mon, 10 Sep 2007 19:57:57 -0400 Youness Alaoui [EMAIL PROTECTED] wrote: Yes, I tried them both, that's the first thing that made me like etk more than ewl, basically because of stability, since the ewl_test kept crashing for many of the widgets, and it had a huge amount of glitches. But also the look and feel seemed to be better. Simple example is the paned window, I like the animated arrows that ewl doesn't have. About the API, I know the ETK API now, but I don't know much about the EWL API yet, I'll probably look into it and see how it goes.. Thanks again for this helpful info. KaKaRoTo Side note, but I think this is a large part of it... I know that's just the default theme or whatever, but the default ETK configuration personally feels much more consistent and good looking than EWL. EWL (in the little experience I've had with it) crashes more, doesn't respect my font preferences, and just has lots of interface issues which are very tiny, and not that noticeable on their own, but add up to just having a not very clean feel. ETK has put forth a lot of effort into making things look good and look consistent (both with itself, and keeping up with the default e17 theme), and I think that has a lot to do with overall perceptions of the two libraries. (Disclaimer: I've written ETK apps, but I've never done any EWL programming, so I really have no idea how nice EWL is internally... I'm just giving my end-user's perspective on things.) Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New website design
not to be offensive, but I don't really like this site design all that much.. It looks old... and dare I say a sf project page? sorry, but the current one looks better imo.--Ian Inc Caldwell On 9/9/07, andres [EMAIL PROTECTED] wrote: El Sunday 09 September 2007 11:36:53 Andreas Volz escribió: Not bad. But the current design is also not bad. If I remember correct the E website engine is very flexible. Perhaps you're able to create a changeable stylesheet. Many websites have this. Nah, I don't think is worth it, I made another design because I don't like several decisions made with the current one, like using tables for laying out options that break when slightly bigger fonts are used or putting a BIG piece of the logo (with no function) occupying like 50% of the screen, etc. But rather than having a lengthy discussion about this I prefer to present my perspectives with my alternative don't decorate, communicate, focus on content, buzzword compliant 2.0 style that it's up to the developers to follow or not. But I think more important than style is content! The current content is... hm... a bit raw in some parts. Perhaps you better spend time into improving the website content. :-? I disagree, if I was a new user and went into the main page of the official website I would have a hard time finding the great (and updated!) articles about EWL hosted in the wiki. Bad or disorganized design nullifies good contents almost completely (I'm not calling the current design bad or disorganized, this is a general statement). Besides, as I said in my first mail, I do have some suggestions for content layout that could be applied regardless of the chosen design and I'm writting content as I can, look Z_en_coder up in the wiki. I'm just worried about most users not knowing my articles in the wiki even exist. But I'm writting content, for example, I'm currently half-way (in my local mirror of the wiki) to a comprehensive application development with Edje article, including not only standard EDC code and C API, but an introduction to evas, ecore, ecore_evas and how they relate to edje, the python and ruby APIs and the ruby based Redact compiler (+ Corrected versions of all code examples I happen to come across while studying this). But as I said, its the developer's call, if they are interested in using a design like this I can work on it further and implement it once we are all satisfied, or I can just continue to write wiki articles. right menu: http://img523.imageshack.us/my.php?image=ewebrightwt0.png I don't like this. There's no visual line between menu end and text start. regards Andreas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net 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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --Inc www.inc-omplete.org www.inc-corporate.org - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On 9/10/07, Jesse Luehrs [EMAIL PROTECTED] wrote: Side note, but I think this is a large part of it... I know that's just the default theme or whatever, but the default ETK configuration personally feels much more consistent and good looking than EWL. EWL (in the little experience I've had with it) crashes more, doesn't respect my font preferences, and just has lots of interface issues which are very tiny, and not that noticeable on their own, but add up to just having a not very clean feel. While I appreciate your feedback, you've just hit a big pet-peeve for me. If you find something that crashes or feels like a bug or inconsistency FILE A BUG! While we are active, we all have limited amounts of time, and we tend to work on things that interest us at the time or are present in the bug lists first. I'm sure the ETK folks would be appreciative of bugs filed for them as well. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Starting programming in EFL
On 9/10/07, Simon TRENY [EMAIL PROTECTED] wrote: 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's just completely wrong. We certainly could take the same approach that ETK does and use specialized handlers for each column type, but we consider it a poor API choice. There is nothing inherent in EWL that requires the rows to be a widget. The idea with tree2 is that we maintain the widget abstraction for providers to avoid additional reference to drawing engine specific objects. So as we abstract more into the engine code, we can maintain fewer references to evas specifics and ease the porting effort. We are currently in the design debugging phase of this effort, and not the optimization phase. Once we have the common code to a point we're happy with, then we will optimize for the fixed row height case (which is what ETK uses), and we only need to maintain widgets for the visible rows, just like ETK only has to maintain evas objects for those rows. We can still support variable height rows when they are useful but default to the fixed height case. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
