On Thu, 19 Jun 2014 12:20:21 -0300 Carlos Carvalho <ccarva...@expertisesolutions.com.br> said:
> Hi raster :) > > please see below. > > On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida > > <felipe.m.alme...@gmail.com> said: > > > > Hey guys. just reading now. looking at emodel.eo a lot of these methods > > have no > > return.... just looking at properties for starters. also > > child_select_get(). > > > > this needs a lot more documentation as it's really mysterious as to what > > this > > does and how it's meant to work. reading the code for the eio emodel i can > > see > > that child_select_get() will call the EMODEL_EVENT_CHILD_SELECTED on the > > object > > inside of this as long as a path is selected. what does load/unload do? > > > > There are child_select_get and child_select_set. yes - but the get returns nothing. this seems really bizarre. it looks like a property by name, but doesn't work like one at all. > The former is used when the application needs to know which (and if) child > is currently selected by the user, so application adds itself as listener > and call select_get and its callback will be invoked. and that's what is bizarre about it. normally you'd have blah_set(10); int val = blah_get(); this doesn't work like that so i star at it in bewilderment. it doesn't follow a pattern being used in most places in efl where a _set/_get pair are basically a property (some read-only, some write-only, some read/write so the get/get existance define that). but this looks like a property, but then doesn't work like one. might i suggest a renaming? like child_select() and then child_select_eval() or something... up for debate. and properties_get, property_get and property_set also have an issue in that they even use property there in the name but dont work like eo properties (above). again - prop_list(), prop_fetch(), prop_set() (as the set does look like a property)... maybe also child_fetch() child_slice_fetch()... it sounds like we need a new convention for this kind of "we return but not by any obvious return value or return pointer - we return by callbacks" (and maybe callback is given directly or is an event callback). but just saying... as i read it... it looks .. odd. > The later happens when the user selects a child and every time it happens > an event is dispatched informing the listeners which child is selected so > the application can do whatever it wants with that information and can > navigate through the directory tree, in the case of eio, delete/create > files, etc.. sure - just the naming makes it seem odd vs existing conventions. :) > load/unload are actually unused because in the beginning of time we tough > to make them to perhaps behave like constructors and so but I don't know if > it makes sense and perhaps they may be removed.. ? i think load/unload are good. they can free memory of child info on unload and load can begin a background dir scan and info collection. we don't load unless we want the data. it's a way of having a dormant "empty" object with minimal footprint until we need the actual data. > > it REALLY needs docs there so people know what the purpose is so we can > > review > > and understand this better. :) > > > > Surely, I totally agree with you and this is on the way and as soon as we > have done I'll let you guys know. cool. i'm waiting on it. :) > > for some symmetry - there is a child_del in the core, but nothing for > > adding > > children. seems a bit... asymmetric to me? also the eio model overrides > > child_del AND has a child_del of its own. why?. they have different input > > params too. for the eio model, can i recommend we have a path property you > > can > > set AND get? so you can create an empty eio model and then point it to a > > path? > > cleaner. a custom constructor is fine but we eventually want to get rid of > > them > > or as many as we can. > > > > EIO indeed overrides child_del and implements its own, it is a kind of yeah. it does BOTH. that is the confusing bit. :) > unwanted indirection since emodel_eio deal with files and directories and > Emodel's child_del is kind of generic. In emodel_eio you'll see that > child_del is redirected to eio_child_del , the later then works directly > with EIO performing eio_dir_unlink (which works for simple files too). This > indirection may be unnecessary and can be removed if code/logic clarity is > improved. i think it is unnecessry. :) it's kind of confusing. "so.. which del do i use? the parent class child del or the eio child del? what is the difference?" :) > Making something like child_add perhaps has a drawback because, as far I > know, the application must know in advance what kind of model it is > constructing. In the case of emodel_eio it is filesystem, but could be > Database stuff or some other thing. sure. but it just seems odd to be asymmetrical. there are many cases where you can add a child generically too. that's actually how eo works itself. :) > Making a generic constructor I don't know if would make much sense because > of different implementations for emodel. But we're are very open to change > this if you think it is a good idea os have something in mind I don't > though about. one thing you can do is define that children are not "real" until you have set up enough information for them to be real. eg is it a file or a dir or a symlink or device inode or hadr link, and what is its name, and maybe what does it point to?. without these its incomplete. i would expect these to be set immediately after creation so it will be pending only temporarily. also this nicely makes renaming easy. just set a new name property. no special rename call. :) same as setting the initial name up. changing what a symlink points to? easy - just set the link property to something else. > > so right now... docs docs - especially at the core like emodel. :) > > > > Yeah! It is on the way. Thanks for your feedback, we'll appreciate. > > > > > > > > Hello, > > > > > > We are implementing a model interface and a few views in elementary > > > and would like feedback. > > > The code is at > > https://github.com/expertisesolutions/efl/tree/emodel-eolian > > > and https://github.com/expertisesolutions/elementary/tree/eo_mvc > > > > > > We've designed a model interface which is tree-like (DAG) where each > > > child is an Eo*, which can itself be a Emodel or not) and each node > > > has properties. And the model is completely asynchronous. > > > > > > There is a list view and a form view in elementary and a EIO emodel in > > > EFL which are used in examples in elementary and for testing in EFL. > > > > > > We developed the model interface like this because we felt this > > > allowed more flexibility with an application being entirely defined in > > > a model class with each child for each frame (using a form view or a > > > specific implemented view for example). > > > > > > Any feedback is appreciated, > > > -- > > > Felipe Magno de Almeida > > > > > > > > ------------------------------------------------------------------------------ > > > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > > > Find What Matters Most in Your Big Data with HPCC Systems > > > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > > > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > > > http://p.sf.net/sfu/hpccsystems > > > _______________________________________________ > > > 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) ras...@rasterman.com > > > > > > > -- > -- > Expertise Solutions > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > 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) ras...@rasterman.com ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
