we have a fundamental problem here.

evas in 1.7:
static void
evas_object_smart_clipped_smart_del(Evas_Object *obj)
{
   CSO_DATA_GET_OR_RETURN(obj, cso);

   if (cso->clipper)
     {
        Evas_Object *clipper = cso->clipper;
        cso->clipper = NULL;
        evas_object_del(clipper);
     }

   _evas_object_smart_members_all_del(obj);

   free(cso);
   evas_object_smart_data_set(obj, NULL);
}

and in in trunk(1.8 to be):
static void
evas_object_smart_clipped_smart_del(Evas_Object *eo_obj)
{
   CSO_DATA_GET_OR_RETURN(eo_obj, cso);

   if (cso->clipper)
     {
        Evas_Object *clipper = cso->clipper;
        cso->clipper = NULL;
        evas_object_del(clipper);
     }

   _evas_object_smart_members_all_del(eo_obj);

   evas_object_smart_data_set(eo_obj, NULL);
}

notice a KEY difference... 1.8 has no free() of cso.

this means that if we add the free() we segv all over now in efl. BUT... if we
dont add it .. we LEAK! because in 1.7 - applications using the smart clipped
smart object were expected to malloc/calloc the cso themselves... BUT they
expected smart_clipped to do the free() so they didnt do it.

this is the now back and forth in terminology about the free of the smart data
or not. in efl 1.7 we have dont need to free. in fact a free in the terminology
smart causes a segv. if we DONT free tho with trunk, we leak now - in an
unlimited way (every time we create any smart obj inheriting from
smart_clipped).

this is basically an abi break. we need a solution. and quickly preferably.
basically to maintain abi and api compat, smart_clipped HAS to do the free().
that's a given. there is no choice here. so how to we make the new eo changes
work with this assumption? eo could override the smart del func and duplicate
its own wherever used if *IT* wants to do the free - that means basically copy
& paste the small bit of code there (duplicate it), OR you create a new smart
clipped class that in evas that is identical except it pushes the freeing back
up to the inheritor (which is what eo expects) and that means everywhere eo is
using smart clipped it needs to change to use this new "smart_clipped_nofree"
class.

right now i lean to making a new nofree class and then adapting all the eo code
that expects to do its own freeing to use that.

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


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to