On 7/10/07, dan sinclair <[EMAIL PROTECTED]> wrote: > > On 9-Jul-07, at 8:13 PM, Hisham Mardam Bey wrote: > > > On 7/9/07, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > >> Hi all, > >> > >> I want to reply before this thread ends discussing only the "how > >> do we > >> patch projects" topic, as it is just a small part of the real > >> problem. > >> I've seen other devs and myself complaining on how things work on > >> e-land, from how the ideas are discussed (design) to how they are > >> implemented (implementation) and what happens between the process > >> with > >> other dependent projects (api breaks?). But instead of saying > >> different solutions we can have, i would prefer to explain what i > >> have > >> in mind from a code perspective, what i have done and what are the > >> problems with current status. > >>
dan, you are misunderstanding why i put code examples here, as i said on my mail, those are to explain the current situation. don't treat them as possible production code. > >> - Canvas Server: This was an idea to allow different process access a > >> canvas space and draw into it (think of them as having the gadcons on > >> different processes) and a simple framebuffer multiplexer. Some time > >> ago, i retook the evoak project, refactored it and implemented it > >> in a > >> different way (as a plugin to evas, and stand alone library), it > >> worked nice enough, but was just a proof of concepts because evas > >> needs many things to be able to use it. (dependencies, internal > >> changes, etc). So this *idea* ended up being nothing, evas should > >> support foreign objects if it wants to avoid the dependency "issue". > >> > > Prototype code, nothing to comment on here. This one was to explain how when you develop something with new features you (mostly) end on evas. I didnt want that code to be included as-is, just poke the dev people about the idea (which was there for a long time), about the problems with evas if we wanted something similar, etc. And of course get the *feedback* from other devs about this. Only answered jose and raster, with no guidelines on what should be the steps to include it or what should evas change in that aspect, i.e no planning . > > > >> - Better support of the fb system specially for embedded devices > >> (interesting how now, everyone seems to be interested on this field). > >> I reworked completely ecore_fb, i sent an email also to the list > >> explaining what i had done, and what was left. (is almost done, what > >> needs to be done is sending the utf8 string of the keypress to the > >> event system). It did has some interest from other devs, but i wasnt > >> satisfied of the approach mainly for one reason: having the input > >> system mixed with the graphics system. In any case, there was no goal > >> on what ecore_fb should be. > >> > > Ok, a proposal and solution that Jorge didn't like, nothing to > comment on here. Totally misunderstood, the ecore_fb code was merged with ecore_li (linux input) a prototype code i did for some projects, but by hisham - moom suggest this was merged into ecore_fb even if i didnt like that idea completely, but was ok. In any case, that solution was good for several developers but it was dependent on an eet patch. The first version was included without problems and of course without interaction on what ecore_fb should be, only raster (and possible mickey) answered to my first ecore_fb thread. But again the people interested didnt setup a roadmap for this lirbary (including me). > > >> - Memory Pool Allocator. I remember the discussion about the memory > >> fragmentation and a need for a double pointer malloc, i already > >> implemented a small library (mem pool) that supports different > >> policies (firstfit, bestfit, etc) through a plugin system, with only > >> one implementation (firstfit) because im not that good on memory > >> algorithms, but with a good and simple interface. This was made > >> public > >> only through irc, with of course, no interest; even if it was a > >> public > >> need. > >> > > Only made available on IRC. That isn't going to get may people > interested as not everyone is on IRC all the time. Send to the list > if you actually want people to look at something. > Funny how sending code to the list also doesnt mean that someone will get interested (as the examples above). Either way, the point here was that there *is* an idea on a possible project people can take and code, but again, the solutions can be multiple, redundant and of course replaced by anyone at any time, because there's only the need but not the path to do it on a "community way". So yes i took it by myself and did a prototype and commented it to dev ppl on irc, with no answer. > > >> - Shared Memory. Some people has said that a cache mechanism is > >> needed > >> between process, to share images and fonts between efl projects > >> from a > >> common place. I have coded a daemon that manages such shm segments > >> using e_dbus as the communication and the previous project as the > >> manager of elements inside the shm segment, with good results (it > >> isnt > >> finished btw). I also remember Cedric's mails about a cache mechanism > >> which wasnt included into evas (can't recall now if it is inside > >> yet). > >> So evas was looking also for a cache mechanism, that (mostly sure) > >> won't be usable from outside and any other app or library wishing to > >> use a similar concept, simply can't. So here arise another problem > >> with evas, its idea of being everything by itself, with its own data > >> types, isnt a good thing. > > Isn't finished, nothing to comment on. Again misunderstood. If something isnt finished doesnt means that you can't comment on it, discuss it, etc. For how long ewl wasnt complete? (not sure if it is now), what does that mean? that nobody can discuss about it. In my opinion that's a good thing to do. The idea here, was again to note how a good concept (a must for some devs) like an inter process cache system has to be taken seriously or at least discussed. Interesting how *again* it ends on evas. Also to note how evas handles its own data types, etc. and the problems with having 3 list types, 2 hashes, a static mempool on evas, a plugin system on ecore that nobody uses (funny how everyone again implements its own plugin loader), etc. > > >> > >> - Eet, one of the main needs of my ecore_fb rework was the array > >> support on eet, i already sent an email on the list (many months ago) > >> which wasnt reviewed. So of course is another problem with the > >> current > >> patch flow. I know i have cvs access here, but wasnt just an addition > >> on the features, but an API break, so i preferred a review and > >> comments before commiting it (as i usually do). > > I believe there was some discussion around if the API break was > actually needed with this patch. Was that ever resolved? This one > seems to have gotten dropped, ping the list again. > There was no discussion on the api break, just a mail from Nathan to note if the both a fixed and a variable array support was needed. The list? who on the list will change eet and it's api? i personally dont change other's code, only if the other devs gives me a go. There's no point on pinging the ml if only one person can do it (raster), for that, i already ping him on irc several times. So, this was to explain another "issue" on who is in charge of what, having raster manages all of the efl core is good and bad, of course is mostly his code, but with the work *we all have* a simple patch can be never reviewed. > > >> > >> - Evas, on every efl related discussion, always ends on evas, i won't > >> explain *again* what are the "problems" or limitations with Evas as i > >> said it too much times. > > Evas is a big piece of code that everything depends on. It makes > sense to be careful with large patches to this one. Sending them as > smaller patches would make life a lot easier for review. Is not about small patches, is about what it needs and how it should be done. Not who review it or how. > > >> > >> So the above just resumes what's going on here, is not that i want to > >> flaunt my coding skills, is just that the above examples, summarize > >> the problems. Poor communication, bad mid/long term goals for each > >> efl > >> component (of course a piece of software is dynamic by nature, but an > >> anarchic way of doing things isnt a good option). Raster, you have > >> said several times (sames applies to me and also to Brian i think) > >> that ecore should and must be split, what is the plan behind it? when > >> should it happen? how? or maybe another one should take the decission > >> and start it? > >> > > I'm sure if someone started it it would be appreciated. So we have to guess that it is appreciated and that it is needed? that's the point. > > >> Almost every projects depends on Evas, so Evas is our bottleneck for > >> features, if we want something new, Evas will (and currently does) > >> limit us. Let's say we want to make evas cache all of its images / > >> fonts (there's no other place where we can think of a cache > >> system, as > >> everything ends on Evas) and that are accessible to other > >> applications, then it should need a way to communicate through a > >> socket (for the shm synchronization), what will happen? does Evas > >> will > >> implement again a socket interface (or a dbus interface in case of my > >> shm daemon) instead of using ecore ones, we won't do it because there > >> will be a double dependency? > >> > > Unless the ecore stuff was split apart and breaks the double dependency. Redundant. It's what i meant. This was one of the arguments to not include evoak's idea into evas, but of course the solution was to split ecore. > > >> I have already said on several times that we need a solution for the > >> current status, from a community point of view and from a technical > >> point of view. If the projects inside the CVS aren't related (as > >> someone suggested) and are just someone's ideas, of course there's no > >> need for it, because there's no community. > >> > > dan > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
