On Thu, 13 Oct 2005 16:51:23 -0500 Nathan Ingersoll <[EMAIL PROTECTED]> babbled:
> raster, I just wanted to clarify a couple of your points. The email linked > that shows a message from Simon that didn't get a response, it was followed > closely by a similar email from Hisham which I did respond to, so I didn't > feel it was necessary to respond with duplicate information on the same > list. The patch submitted had problems, and I asked him to test it against > some existing code and did not receive any further communication on the > matter. My guess is he judged EWL based on the grid widget which he was > trying to patch. That widget is one of a few containers that have gone > unmaintained, so the code is not in good condition. > > Maybe I hid it well in my previous messages, but there IS a degree of > frustration on my part. Primarily, because I felt (and currently feel) that > there was intentional deception when it was not necessary. The IRC > communications we've had (Hisham, Simon, dan and myself) have been > frustrating, unproductive and filled with generic attacks on the design > without any specific design faults given. I illustrated an example of this > in a previous message. It could be a language barrier, but I've never had > language problems with Hisham prior to this, so that would surprise me. So > my frustration doesn't stem from having another set of widgets added to CVS, > but the fact that I can't get any reasoned response on questions I've asked. > I also got the impression that Simon and Hisham were frustrated because dan > and I were not willing to say that EWL had to be rewritten, which leads me > to believe they intentionally kept it quiet to avoid conflict with dan and > myself. I'm willing to take some blame if they felt I was unwilling to > listen, but I made my best effort to get an explanation of their reasoning. > > How many times have their been EWL rewrites, new layout engines, and widget > wrappers that have appeared in CVS over the years? At least 5 that I know of > (the current code base is #2 after massive evolution). I didn't really care > then and don't really care now. The only thing different in this case is > that the authors of those projects talked about what they were doing, > explained what they were trying to accomplish, and were communicative about > the process. > > Looking ahead, if Simon and Hisham are committed to working as part of the > team, one excellent way to extend an olive branch would be to BSD license > their theme. With the heavy GTK influence I can understand Simon's > reluctance to use a different license, but that only covers the code, not > the theme. I did a quick port of their theme to EWL and it looked pretty > damn good, but there's no chance of this work going into the EWL theme > unless that license is changed. The way the two use edje is too different at > this time to make themes that can be effectively shared between the two, but > I don't see why some sharing can't occur at this level. ETK has the benefit > of using EWL code without fear of license complications, it would be nice if > EWL could do the same with the ETK theme. i do think that is a major issue. you dont license something the same as another project just because the other project heavily influenced its design and ideas and structure. license applies to COPIES, not influences, ideas, inspiration. it has to be pretty much a direct copy (and then a derivative from there). i agree that etk, being lgpl, is not productinve in terms of it being able to share back. i know i dont plan on even thinking of "blessing it" even as official competition - if there can be such a thing (you get the idea) as long as it's lgpl. it basically stands out as a sore thumb in cvs and i 100% agree with everyone (except simon) on this issue. it should be changed just so it can be shared - you can share themes (well take the theme and adapt for ewl), or you can find useful code in etk and use it in ewl, and vice-versa. ewl is still very mature and is licensed well and has a lot of hard work from nathan, dan and others over the years behind it. its there and isn't going anywhere. it has rough edges, sure - as does a lot of code in cvs. evas, ecore and edje included. > I think I've said all I can on this topic, and we've all spent enough time > on it. I do appreciate all of the support from the various developers that > stepped forward when things smelled rotten. I think this has shown one of > the biggest issues this project has always had, communicating ideas and > plans between developers. We have lost a few good devs because of this in > the past and it seems like a ridiculous reason to me. I don't think this is > something that can be managed or imposed, but I do think we can improve it > pretty simply. > > Right now, most design discussion happens on IRC, which is great for quick > discussion and brainstorming, but doesn't reach the full audience. So if you > want to help improve communication, drop the list a note when you have an > idea that you might implement. I'm not saying write a long explanation > documenting every detail, just something along the lines of "Hey all, I'm > thinking about writing this application using such and such a method for > organizing the data, anyone have experience with this method or spot some > issues in the idea?" Get some dialog started about it, and you might find > you end up with better results or people willing to pitch in. I'll try to > follow my own advice here and bring up some EWL changes that have been in > the works. i think a big problem is the spread-out nature of the team. to discuss on email takes days. you have to wait for timezones to go through their daily routine. if u are agonising over something - it's nice to get a quick discussion, feedback and get on with it. i agree that maybe this all hilights a bit of need to discuss a bit more. but then again i know personally i'm hesitant due to the massive timesink email is already. i think too that havi0ng code to REFER to for discussion is good. ie "here is what i mean to say... in CODE". as programmers code is something that transcends language barriers for all of us and is a great way of articulating specific ideas. even if the code is a throw-away thing. proto/ is pretty much the intended forum for such stuff unless it sa small part of an existing large project. we need to do 2 things here. 1. be accepting that code going into proto is nto to be judged, vetoed, ostracised out of the proejct etc. it's a sandpit to help with developing ideas, discussions, excercizing some other bit of code ina certian way, etc. and 2. maybe moving some more development discussion to the enlightenment-devel list and trying to encourage users to put their user queries and help on enlightenment-users so devel is free for code/design/etc related discussion, enlightenment-web being revived by ben for website discussion etc. so does everyone seem agreed we should try re-assign priorities to the mailing lists to be more "on topic" (make some announcements and make an effort to redirect mails to users or web lists etc.) and then maybe free up some mail "bandwidth" for more discussion? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- 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
