Cedric BAIL schrieb: > On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> Vincent Torri schrieb: >> >>> I think that Hisham wants you to put your code in edata, and not create >>> another lib. >>> >>> >> Unfortunately, it isn't that easy. We have two (or with other counting 3 >> or 4) list implementations and two hash implementations. Since their API >> is totally different, especially for the lists, we cannot simply choose >> one of them and port the rest to that API without an incredibly huge >> amount of work. So the only way we can handle it is to have both >> implementations parallel in the data lib. But how are we going to name >> them? Maybe we name the evas_list edt_nodes or we name the ecore_list >> edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the >> evas_list. For the hashs the situation is a bit better. After Nathan has >> his ecore_hash improvements in. We can make the evas_hash a wrapper >> around it. But we still need to think about a name for it, maybe >> edt_strhash. Where we can really unify stuff is for ecore_list2 and >> evas_object_list, i think we can take there turran's eina_inlist. And >> edata has also an edata_array, what are we going to use evas_array or >> edata_array, or do we also need both? Besides that I wouldn't put >> ecore_tree into the new lib before it is fixed, it is currently in an >> unusable state. >> > > We also have some inthash and we need hash indexed by two int for the > font subsytem. Maybe, we can use there ecore_hash, but i don't know if it fits the needs. > And you forgot the simple hash and list implementation > of eet :-) Yes, the situation is a bit complex... > Yup, i know that it is very complex :), especially if we want to unify things. > >> As you can see there are many open questions, that needs to be answered >> first. That's why raster had the idea to first put the string pool into >> the new lib, because - as mentioned before - the API is the same. Of >> course we still need to discuss what is going into that lib and how. If >> people prefer to discuss it yet and do the whole stuff later at once, we >> can do this as well, but just taking edata doesn't work. >> > > But why didn't we just put eina inside the libs cvs directory (svn > checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And > start hacking from here. We can then slowly switch evas , ecore and > eet to the data type eina provide or the one we add to eina. It should > be easier to start from something with code and hack than agree on > what we should put in. But if you are going to do the work, I will > agree and help on this project as it's something we need to do. >
Iirc, there are some things in eina that raster didn't want to have in the data type. I haven't looked into eina lately, but last time i did he started to use evas_list instead of ecore_list, the problem is that i don't think we can choose one of them and then port the rest to that, it isn't only a different way of API, it also results in a different code structure and some things aren't possible with the one implementation, which aren't possible with the other. So i think we have to go with boths, if we don't want to move the release date into the fare future. Using both reduce the porting to the new API to a simple sed script. I don't think, that it is much work to put things together, the code is already here, no matter if we take it from evas, ecore, edata or eina. Some lines of sed, maybe a reindent and then adding it to the Makefile.am and the header to the Edt.h (or how name it). > >> I hope that clarify things >> > > I just don't like edt as a name, but that's really not something > important :-) So as long as we have a plan to merge all data type into > one lib, I will be happy. > I'd prefer eina, as well :). But that would break then turran's code, if we don't take all of its code. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
