Jorge Luis Zapata Muga wrote: > 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 . >
Jose and Raster _are_ the most familiar with Evas. What's the point of me commenting on an Evas patch? I don't know how it works, I've only touched the API and some textblock. Ok, so set out the steps and start working towards them. Start doing some planning if you want a plan layed out. >> >> >> >> - 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). > Again, Raster and Mickey are probably the two best people to talk about framebuffer. Not everyone is going to comment on something. We discuss Ewl patches it's Nathan, Peter and myself. That's it. The people that know the code are the ones I want comments from. >> >> >> - 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. > Sending code to the list is more likely to get it seen then to IRC. I've never heard of this patch or this work before you mentioned it. Has Raster? Has Nathan? This is at least a patch people could comment on without having to know Evas. This is how the community works. If someone wants something they write it. If they get it done, we'll take a look at it. We don't sit around and say, we have to have x done by may 1, then y done by may 2nd. You work on x, we'll work on y. People leave way too often for that. Their jobs pop up. Whatever. >> >> >> - 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. > Have you presented it to anyone to look at? I've heard about it through Brian but haven't seen anything on the lists. I haven't seen anything in IRC either. How can we comment if you don't give the code out to begin with? In terms of getting included into cvs (which is how i took your email), nothing to comment on if it isn't finished. >> >> >> >> >> - 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. > >> Anyone can change EET and it's API. But, if you break the API you better be sure it's the right way to do it. If Raster doesn't like the change, well, we've got CVS revert. >> >> >> >> - 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. > Ok, we've had this discussion about what Evas needs and how it should be done (I never read them as I don't work on Evas). Does that not give you a starting point? Take what you discussed and go from there. Just start working on it. >> >> >> >> >> 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. > Yes, that's how it works. In most cases it's what _you_ need. If _you_ want it you write it. Brian and I wanted Engrave so we wrote it. I wanted to see if I could do Efreet so we wrote it. In both cases they were appreciated. But that was an after effect. >> >> >> 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. > How is that redundant? You only have to split it once. There you go, once you've split Ecore you can start doing Evoke inside Evas. You've got a plan now. 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
