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. >> >> - 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. >> - 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. >> - 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. >> - 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. >> >> - 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. >> >> - 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. >> >> 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. >> 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. >> 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
