On Thursday, 06 October 2005, at 03:20:19 (-0500), Nathan Ingersoll wrote: > > 1) EWL just doesn't FEEL right. Meaning: When you open up an EWL > > application (e.g. e_util_eapp_edit), things don't respond the way one > > would expect. Resizing is often buggy, cursors / highlighting in text fields > > is strange, etc. > > There are definitely some issues here but I think they've improved > considerably over the last year. There are examples of some fairly > complex layout being done successfully in the test app now as well > as a filemanager written by chaos. The filedialog in particular is > packed pretty nicely, along with the theme test which shows off some > of the theming features EWL incorporates.
Are there minor, mostly-cosmetic issues here and there with EWL? Yes. Are there features missing from some widgets? Yes. Is that a design flaw that requires a rewrite? NO. > I think we can be cut some slack on the text fields as they were > completely reworked this summer and are fairly complex. They do a > reasonable job towards handling multiline text manipulation with > textblock, which is not an easy thing to do, as CodeWarrior should > know. We do need some auto-scrolling code added, but I've written > that code enough times (Epplets, and a few versions of EWL's text > handlers) that I'd rather not do it again. Again, this is simply additional code that must be written, not a design flaw. > 2) It would take longer to learn the EWL internals to be able to > > meaningfully contribute than it would to simply start afresh. That is a crock of shit if I ever heard one. It always takes more time to create something new of equal calibur than it does to learn what's already there. The only way it takes less time to "start afresh" is there are serious design flaws that can only be overcome by a complete bottom-to-top overhaul. And NOT ONE concrete example of a true design flaw has been pointed out yet. Not even one. > The argument being made is that it's easier to design and write > 12985 lines of code and documentation spread across 70 files than it > is to read and understand 11193 lines of code and documentation? Anyone with half a brain should know that that isn't true. This argument is simply an example of grasping at straws in an effort to forward one's own political agenda (in this case, ETK) when one simply cannot come up with *actual* valid reasons. > 3) EWL was designed for Ebits and the original incarnations of Evas and > > Ecore. The many moves to newer > > libraries (Edje, modern Evas/Ecore), although commendable, may have > > introduced a number of bugs. So what? I could also say, "ETK, while commendable, has introduced a number of bugs." And judging by the number of stories I've heard here and on IRC about ETK seg-faulting out the ass, I'd be talking about very real, very concrete bugs that DO EXIST. You're talking about bugs that MAY or MAY NOT exist. > Do we not see the major logic gap here? Did anyone bother to ask how > much the code changed with those ports? Would you be surprised if I > said that each of those ports involved changing about 100 lines of > code? All of these ports improved the code because the basis it was > built on was more solid and gave us a chance to learn where code > duplication crept in and refactor it. > > Currently, EWL has 193 references to Evas functions and 31 > references to Edje calls. If for some reason there was another Evas > rewrite, or a better canvas or Edje-like lib came around that worked > on a somewhat similar model, EWL could be ported fairly easily. In > fact, we could split out these points into theme engine hooks and > drawing methods if we really saw a good need to support more than > Evas and Edje (plus renaming a few internal functions). I appreciate that you are able to respond to the FUD with actual, well-thought-out arguments. I just wish those in the ETK "camp" could do likewise. > You're right about the looks, I've changed the default theme to the > e17 for now to give it a better match to the default window manager > look. I don't know how many times I can say it, but WE NEED HELP > THEMING! I am decent with basic graphics, but given the choice > between working on code and working on the theme, the code always > wins. A lot of the default theme is just hacks I put in place so I > could see the results of the code. The e17 theme is at least better > than that. And the look of the default theme has NOTHING WHATSOEVER to do with code or design, and it certainly does not make an argument for a rewrite. > Good question, and there only one answer I can give you: it's my > fault. The base of EWL has been changing and evolving, making it > very difficult to have a stable API to write higher level widgets on > top of and to debug some of the issues with lower level widgets. It > has stabilized a fair amount over the last year which has allowed us > to work out more of the layout issues. There has been a ton of work > put into increasing code re-use as much as I can and that has > impacted assumptions that other programmers can make as well as made > debugging more difficult for some cases. There's also a complete lack of debugging infrastructure in E code in general. Run "Eterm --debug 2" sometime and look at how much information is hidden in there waiting to be revealed. And it can be compiled in or out and turned on or off at will. Contrast this with E and related projects where "debugging" printf calls are thrown in and out (and in again) with haphazard giddyness. > The project aspect I really don't care that much about. They're > welcome to do their own toolkit project, there are plenty of them > out there and it's a good learning experience, but the fact that > their motivations seem so misguided and that they have been > attacking work that they admit to knowing little about, that bothers > me a lot. Yes, EWL is my "baby" but I'm very open to suggestions on > how to improve it. This is why I've asked MoOm and CodeWarrior to > PLEASE (yes, I'm asking again) point out what the design issues > truly are if they see some. Then we can do an evaluation to > determine if the issues are such fundamental flaws that changing the > current code base doesn't make sense. The fundamental problem here is that having ETK in the "official" E CVS tree lends it credibility, and based on the "discussions" so far (which have consisted almost entirely of one side asking for concrete examples and the other side ignoring their requests while continuing to whine), it does not come close to deserving that credibility. > Something CodeWarrior mentioned on IRC was the fact that EWL had been rather > quiet for a while until ETK hit CVS, so the competition must have sparked > the activity. > > This is wrong, it was just coincidence. It's also a LIE. Note the following monthly totals of CVS commits for 2005: May 27 June 73 July 62 August 54 September 40 ETK showed up on October 1st. On Saturday, 08 October 2005, at 10:25:43 (+0200), Simon TRENY wrote: > First, I have to say that I'm sorry for having kept Etk secret and > send it to the CVS without any notification, it was probably the > worst way to proceed. Yes, it was the worst way to proceed, and it clearly shows that your motives were not above-board. As to whether or not you're actually sorry, I honestly don't believe you. I think you decided it was easier to apologize afterward than to ask permission beforehand. I believe it was a conscious decision on your part to not discuss the situation with anyone. > Now, the reasons why I have started Etk: as I always said, I wasn't > fully satisfied with ewl because it didn't worked as I expected it > to do. So I tried for a (short, I agree) moment to improve it by > making a patch for the grid container (which didn't solve all the > problems, but the idea of the fix was there), by making a theme (it > has never been finished because there were a lot of widget > size/placement problem with this theme). I also send a list of 4 > bugs/incorrect behaviors for the menu widgets, but they've never > been fixed. This is not a design flaw. This is laziness on your part. You made a half-assed (if that) effort to help out, and then you decided that you were going to do things your own way and to Hell with the rest of the project. > Now, that's true that Etk and Ewl are in direct competition, both > dev teams won't give up their job There is only one "dev team," not two, and you're either a part of it or against it. > The only solution I see is that the two libs will have to coexist, Hardly. Another solution (and my favorite, by the way) is that ETK be removed from CVS. You can start your own project on SourceForge if you wish, but your underhanded tactics and complete disregard for teamwork do far more to harm the community than to help it. I would rather have one less person helping out than have to deal with actions like this. If there is a real design flaw in EWL that prevents it from moving forward, let's hear it. Otherwise it's just your ego driving an attempted coup, and frankly you can take both elsewhere. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "I have gotten into the habit of recording important meetings. One never knows when an inconvenient truth will fall between the cracks and vanish." -- Ambassador Londo Mollari, Babylon Five ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
