I see. I was getting totally confused by that. This whole time I thought
that the functions got the func.data, and not the item data.
This makes a lot more sense now
On Sun, Nov 14, 2010 at 3:20 PM, Carsten Haitzler <ras...@rasterman.com>wrote:
> On Sun, 14 Nov 2010 13:12:41 +0200 Viktor Kojouharov <
> vkojouha...@gmail.com>
> 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
> > <ras...@rasterman.com>wrote:
> >
> > > On Sun, 14 Nov 2010 12:28:53 +0200 Viktor Kojouharov <
> > > vkojouha...@gmail.com>
> > > 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 <
> ras...@rasterman.com
> > > >wrote:
> > > >
> > > > > On Sun, 14 Nov 2010 04:34:27 +0200 Viktor Kojouharov <
> > > > > vkojouha...@gmail.com>
> > > > > 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 <
> > > ras...@rasterman.com
> > > > > >wrote:
> > > > > >
> > > > > > > On Sat, 13 Nov 2010 18:54:38 +0200 Viktor Kojouharov <
> > > > > > > vkojouha...@gmail.com>
> > > > > > > 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
> > > > > > > > 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
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > --------------
> > > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > > > >
> > > > >
> > >
> > >
> > > --
> > > ------------- Codito, ergo sum - "I code, therefore I am"
> --------------
> > > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > >
> > >
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
