Re: [E-devel] gen(grid|list)_item del function and its parameters

[Carsten H. (T. R. <ra...@ra...>]

On Sun, 14 Nov 2010 13:12:41 +0200 Viktor Kojouharov <vko...@gm...>
said:

no we aren't:

10:20PM ~/C/elementary/src/lib > grep -- '->func.del(' elm_gengrid.c
     item->gic->func.del((void *)item->base.data, item->wd->self);
          item->gic->func.del((void *)item->base.data, item->wd->self);
          item->gic->func.del((void *)item->base.data, wd->self);
10:20PM ~/C/elementary/src/lib > grep -- '->func.del(' elm_genlist.c
     it->itc->func.del((void *)it->base.data, it->base.widget);
           it->itc->func.del((void *)it->base.data, it->base.widget);
           it->itc->func.del((void *)it->base.data, it->base.widget);

base.data - not func.

> Yes. And I'm talking about the item data. We are getting func.data in the
> del function, so we can clean that, but we can't clean out the item data
> itself, can we? But if we are allowed to set the item data, then we should
> always be able to clean it up.
> 
> On Sun, Nov 14, 2010 at 12:57 PM, Carsten Haitzler
> <ra...@ra...>wrote:
> 
> > On Sun, 14 Nov 2010 12:28:53 +0200 Viktor Kojouharov <
> > vko...@gm...>
> > said:
> >
> > read more carefully. func_data which is passed to the select callback func
> > vs
> > data which is the item data. :)
> >
> > > That doesn't seem right.
> > >
> > >  elm_gengrid_item_data_set effectively calls elm_widget_item_data_set,
> > which
> > > sets the data in Elm_Widget_Item->data, whereas the data that is passed
> > to
> > > all the append|prepend functions is stored in
> > Elm_Gengrid_Item->func.data.
> > > To me, they look like totally different places, unless I'm missing
> > > something.
> > >
> > > On Sun, Nov 14, 2010 at 5:11 AM, Carsten Haitzler <ra...@ra...
> > >wrote:
> > >
> > > > On Sun, 14 Nov 2010 04:34:27 +0200 Viktor Kojouharov <
> > > > vko...@gm...>
> > > > said:
> > > >
> > > > no - it's the one and the same data - if u set it (change it later for
> > that
> > > > item) then the new data pointer you set will be passed to the del and
> > other
> > > > class calls.
> > > >
> > > > > you get the item that that was passed when item_append|prepend was
> > > > called.
> > > > > But you can also call elm_gengrid_item_data_set, and if I red the
> > code
> > > > > correctly, that doesn't touch the previous data, but sets a whole new
> > > > one.
> > > > > And this is the one that you cannot get during the deletion of the
> > item.
> > > > >
> > > > > On Sun, Nov 14, 2010 at 4:13 AM, Carsten Haitzler <
> > ra...@ra...
> > > > >wrote:
> > > > >
> > > > > > On Sat, 13 Nov 2010 18:54:38 +0200 Viktor Kojouharov <
> > > > > > vko...@gm...>
> > > > > > said:
> > > > > >
> > > > > > because it gets the item DATA that is set (the app-side data) for
> > it to
> > > > > > clean
> > > > > > up/delete. genlist/grid will delete the object that is the item
> > itself.
> > > > so
> > > > > > you
> > > > > > don't get it. if you want to clean up something in the object of
> > the
> > > > item
> > > > > > itself - you can register and evas del callback on it to clean up
> > > > attached
> > > > > > keys. as genlist/grid add and delete these list item objects
> > > > dynamically.
> > > > > > the
> > > > > > evas object you are passed is the genlist itself. you know what
> > genlist
> > > > it
> > > > > > was
> > > > > > your data belonged to - you may or may not use that. the
> > genlist/grid
> > > > items
> > > > > > though - i fail to see why you need it? you got the pointer you
> > passed
> > > > in
> > > > > > on
> > > > > > create (userdata) as *data in the del cb for you to clean up. you
> > have
> > > > the
> > > > > > genlist/grid pointer itself in case you need it.
> > > > > >
> > > > > > > Why doesn't that  function receive the actual item object as a
> > > > parameter?
> > > > > > > The object itself can hold user data, which might need cleaning
> > when
> > > > the
> > > > > > > item is deleted. From that function however, there's no way to
> > clear
> > > > that
> > > > > > > data, since all you get is an evas_object (whose usefulness
> > escapes
> > > > me).
> > > > > > May
> > > > > > > I propose that we also pass the gen*_item as a third parameter to
> > the
> > > > del
> > > > > > > functions?
> > > > > > >
> > > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > > > Centralized Desktop Delivery: Dell and VMware Reference
> > Architecture
> > > > > > > Simplifying enterprise desktop deployment and management using
> > > > > > > Dell EqualLogic storage and VMware View: A highly scalable,
> > > > end-to-end
> > > > > > > client virtualization framework. Read more!
> > > > > > > http://p.sf.net/sfu/dell-eql-dev2dev
> > > > > > > _______________________________________________
> > > > > > > enlightenment-devel mailing list
> > > > > > > enl...@li...
> > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > > --------------
> > > > > > The Rasterman (Carsten Haitzler)    ra...@ra...
> > > > > >
> > > > > >
> > > >
> > > >
> > > > --
> > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > --------------
> > > > The Rasterman (Carsten Haitzler)    ra...@ra...
> > > >
> > > >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    ra...@ra...
> >
> >


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...