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". > > - 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. > > - 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. > > - 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. > > - 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). > > - 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. > > 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? > > 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? > > 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. >
I am personally still waiting on an answer to this email, mainly from Raster. Jorge is bringing up some good points. -- Hisham Mardam Bey http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------------------------- 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
