On Mon, 9 Jul 2007 12:27:34 +0200 "Jorge Luis Zapata Muga" <[EMAIL PROTECTED]> babbled:
> 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". last i knew you were still working on this. yes evas needs to be able to virtualise objects off into pluggable modules - like engines, as well as callback-provided objects (much like smart objects - but done at the lower raw object level). existing objects need to be able to be "replaced" by apps and other libs - sure. though a lot of this requires our engine api settle down as these objects will need to do their own rendering. again - proof of concept/idea. i dropped evoak because it was going to turn out to be too much work (for now) and i decided to "worry about this some other day". it did prove that i could do fancy graphics with incredibly low bandwidth. (the default evoak demo ran and animated within 32kbit - a dialup connection). i hadn't even gotten to being able to put parts of the UI logic "server-side" (much like javascript is "browser-side"). > - 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. we have modified ecore_fb a lot over time - your patches and others too. ecore_fb simply provides enough utilities to handle fb management. it's a bit of a mixed bag of code and can be cleaned up, but we actually have very little driving the need for it. embedded stuff is moving to X. fb would be mostly useful for things like boot animations/status and other very specialised apps. > - 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. i think from memory what you implemented didnt do double-pointers. i.e. Evas_Object ** instead of the current Evas_Object * at the api level - as long as an object is opaque, you can return any pointer type you like, but internally it'd be a double-pointer with routines to be able to "defrag" (re-shuffle memory locations around to compact memory down and reduce memory space/page usage). again - this probably is sitting waiting for it to be complete. > - 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. never saw this? > - 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). array support is in - now, and with no breaks. > - 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. yes - it has limitations and issues. not surprising. though they are probably not as bad as you think, and can be fixed over time. > 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? yes - i have dropped a lot. reviewing patches takes a fair bit of time. i literally am fresh out of spare time - how much do you see me committing to cvs these days? i literally am almost retired from e. i am lucky if i can keep up with e-mail. this thread is consuming a fair bit of coding time for me - and for me since i have so little to start with, the current email rate is consuming basically 100% of any time i have to work on e/efl. and i don't even have time for the email that comes in. > 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? or just provide a way like xlib does to GET the fd of "evas" and "Select" on it in an ecore_fd_handler - when the fd wakes up - call the "evas_process()" or whatever call to process messages from other daemons etc. same as x. it can be done without circular deps. > 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. well for starters we now have our own web servers and have our own bugzilla - putting patches there might mean they won't get lost as easily. i have 100000's of emails stored in archives and 10000's in my current mailboxes. i lose emails. i sometimes mark them and forget them - they slide away in my inbox into the "so old i eventually archive them up into a tarball and never see them again" land. if the originators do not regularly ping me - i probably will forget them. to help with this we need MORE people these things go through. i am a single bottleneck and point of failure. i have less and less time. my time is spent on work that demands more and more of me. last week i worked 6 days of the week. the 7th i spent cleaning the house etc. because guests were coming. i am lucky to get enough time to READ my email, let alone respond. > ------------------------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
