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