Besides to eina issues, I found that I added experimental ecore API by mistake. > EAPI int ecore_main_loop_iterate_may_block(int may_block)
That was added two month ago by accident. http://trac.enlightenment.org/e/changeset/67685 The API is to run main loop iteration once with block/non_block option. We already have a API to run main loop iteration once only with blocking status. > EAPI int ecore_main_loop_iterate(void); I needed to have block/non_block optional API for a test application. Because the API was in by accident, there is no API declarations in header and no documentation. Is it ok to keep this API and add documentations? I think this API is ok and needed in some cases. glib main loop also has this kind of API. Daniel Juyung Seo (SeoZ) On Tue, Apr 3, 2012 at 7:53 AM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > Hi all, > > I'm bit busy at the moment and can't discuss much details, but a > summary is that I'd really like it to be available as for now. > > To clarify few things: > > - Eina_Value: it's gold, really. No idea why it was mixed into Model > discussion. Value purpose is not dependent on Model, although model > does use it to exchange properties in a safe way. When designing it > I've researched how glib and qt does that, we could do more with > optimized handling for arrays. > > - Eina_Model: although test coverage is not 100%, it does come with > much more test than the average code in SVN. ProFUSION is using it for > customers code without issue, mostly to abstract data access to DB. > All in all I'm satisfied with the API for MODEL (DATA) usage. > > - during Eina_Model development, I create the Interface concept, with > multiple interfaces per type, and interfaces could extend multiple > interfaces. But the implementation (internals) assumed for MODEL > (data) the common case is not to have multiple INDEPENDENT interfaces > to implement the same, thus I implemented the interface lookups in a > naive way. THIS is marked in code for future improvements. > http://trac.enlightenment.org/e/browser/trunk/eina/src/lib/eina_model.c#L524 > Again, this is an internal issue and can be fixed without changing > API or ABI. The only synthetic example that exposes this behavior is > hard. This is example eina_model_04 in SVN, and the "fix" was to force > an unneeded dependency between interfaces. > > - python, which uses the same object implementation for everything, > used a similar naive implementation for almost 10 years before > changing it. > > - the fix for the above problem is suggested in the TODO, it's about > changing the algorithm that sorts the dependencies to consider initial > ordering as well when pulling the roots of topological sort. > > - interfaces for models/data is more to help people to override a > single part without having to do much work. For example the sole usage > of it now is to independently handle properties and children. > > - aside from interfaces exceptional corner cases, I did not see any > other relevant comment to Model; > > - I don't consider the code to be rushed in, as it's in SVN for more > than 2 months. It went through reviews, documentation, examples and is > being used in our projects without issues (the found issues were fixed > in SVN). > > - Removing it because it's not in use is chicken-egg. It will not be > used if it does not exist. As I said I'm bit busy to code right now, > but I would use Eina_Model to implement, at least (no particular > order): > * SQL loader in esql; > * Eet loader and saver; > * Eio browser; > * Enjoy, allowing plugins to provide backend-independent data (SQL > as now, but also FS or network/last.fm). > * Elementary to provide views (genlist/grid variants); > * Python: to let Python objects be used by C code > implementing/using Eina_Model. > > - I'm bit sad to see that knowing your code is not perfect and > flagging it with TODO to help others is seen as a bad thing. I always > marked like that, while others just omit those. I don't see why it > would make it a blocker for inclusion. > > Again, this code is intended to map data in a common protocol so we > reduce code duplication everywhere. It is based on properties and > children. It does events signaling to notify of changes. It does > reference counting as multiple views may hold the data. > And for these cases I really fail to see how it's broken, badly > designed or with flaws. > > What does seems to happen is a confusion with general objects. This is > not general object. Don't expect Evas_Object to be converted to > Eina_Model because it has nothing to do. What you should expect is > every data provider to talk this API and suddenly you could show a > list of something in Elementary without effort. > > []s > -- Gustavo > > > On Mon, Apr 2, 2012 at 4:03 AM, Tom Hacohen <tom.haco...@samsung.com> wrote: >> >> On 02/04/12 05:39, Carsten Haitzler (The Rasterman) wrote: >> > i was hoping/expecting gustavo to appear in this thread and make his >> > case. >> > >> >> He's probably unavailable atm. Anyhow, the most important point I raised >> is the last one. Given that *nothing* in the efl uses it, why are we >> trying to rush it in? > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > enlightenment-users mailing list > enlightenment-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
