This problem was that because the refcount is now shared between the
parent and the programmer in some cases we would get a double unref. An
example way of triggering it is creating a button and putting it in a
box. The box has a callback registered that when the button is deleted
it would delete itself too. The problem is that the delete callback is
called the button is removed from the box thus causing the box to unref
it again (because of the parent), although the refcount was already
accounted for.
There is another more convoluted scenario that I have yet to fix.
Thanks to raster for reporting.
Previously events used to use class name as a prefix and ignored eo_prefix
when specified. This is no longer the case. Events follow eo_prefix by default
now. In order to get around this for classes where this is undesirable, a new
field event_prefix was added which takes priority over eo_prefix. If neither
is specified, class name is used like previously.
@feature
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
This commit breaks behaviour!
Re-parenting no longer detaches composite objects, so watch out.
Now you can have an object be a composite object of an object although
it's not its child. This allows widgets to do things like having an
object as the child of a child object while still making it a composite
object to the main object.
With this change, composite objects don't keep a reference to the child,
but instead composite "bonds" are implicitly removed when either the
parent or the child are destructed.
Summary:
object_find is more generic, so other mechanisms can also reuse the
code.
The object itself has to support the function, so there is no need for
eo_isa which would have a negative performance impact.
The base class implementation calls interface_get on the parent, so a
override of the function can just call the super function to continue in
the recursion.
Test Plan: just run the eo test suite
Reviewers: raster, tasn, jpeg
Reviewed By: tasn, jpeg
Subscribers: felipealmeida, netstar, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3909
This code is an absolute mess. This is the first step towards fixing that.
This cleanup let me find a bug that would have printed errors when using
Eina_Value so I fixed that too.
This was done following a feature request by @raster. There was no real
reason for it not to be an eo function and this gives us more
flexibility.
The reason why this done was to provide a way for classes to do special
things when an object deletion was requested, for example in the case of
Evas, hide the object.
so geneirc data, wrefs, comments and id's are not that common so put
them all into their own memory segment that's allocated separately to
the core object so we only use this memory when needed. we already had
an extension section anyway so it's not new - just using it now for
more of the rarer bits of data. 2 more pointers gone from most objects
anyway and now extension code handling is a bit cleaner.
base class objects will ask their parent object to get the loop. this
means it recurses all objects regardless of type until it finds an
object that returns a proper loop object - eg a loop object returns
itself, a window, gfx/ui object returns the mainloop object etc. etc.
@feature
The idea is that when you are processing those events from within
they won't call twice any of the event until all of them are processed
at least once (Or one of them did return EINA_FALSE).
this finds child objects by walking the child tree searching children
by using the search string which can be name, class:name and both
class and name can also be a glob.
@feature
eina value would allow any value to be attached to an eo object and
also be freed nicely too. this would allow any generic data to go
there without overloading a void * that us c coders love to abuse.
@feature
also useful for debugging and more. this also makes both name/id and
comment an extension blob of ram so objects dont keep growing
boundlessly in memory usage/size
@feature
also evas objects have names too, so add this as this was discussed
and now the feature is in. there is nothing to find objects by name
yet. that's more api's and features to add after this.
@feature
this adds eo_key_obj_set/get/del() like with data but for object
handles so the obj is ref'd as long as the key and parent obj exists
and then unreffed on deletion. it also tracks deletion of reffed
objects like weak refs and then removes the key automatically.
@feature
Mostly unused vars following the removal of eo_do_ret().
However, there are some cases where the migration script got some things
wrong, and I had to manually fix them.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
Change the Eo event callback signature to what suggested by Marcel
Hollerbach in the ML (Thread: EFL interface change - Animator).
This changes the signature of callbacks from
Eina_Bool cb(void *data, Eo *obj const Eo_Event_Description *desc, void *event_info)
to
Eina_Bool cb(void *data, const Eo_Event *event)
Where Eo_Event is a structure that holds these parameters.
This makes it less annoying to not use parameters (you end up using
EINA_UNUSED less), and allows for future extensions to callback
parameters.
@feature
Coverity CID1339783 says that we have a potential resource leak here.
'cb' gets allocated via calloc, but is not freed if we end up
returning here
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This reverts commit 4b116627c2.
This can't be done, because the freeze state can change from within the
callbacks so you need to check if events are frozen every time.
My previous patch to this piece of code
(37f84b7e96), caused a significant
performance regression. This is such a hot path, that even accessing the
strings when we don't have to slows things down drastically. It makes
more sense to just store it in the structure.
This commit breaks ABI (though most people probably won't even need to
recompile anything else because of the memory layout).
It was discussed on IRC and was decided this is a big enough issue to
warrant a fix during the freeze.
@fix
Commit 37f84b7e96 introduced a few changes
to the callback matching mechanism that made it so sometimes callbacks
would be triggered for the wrong events. The problem was there because
of the support for legacy events that forces to do string comparison
instead of the usual pointer comparison. We should only do string
comparison when we are certain one of the callbacks is a legacy
generated one.
Regression tests will follow tomorrow. Way too late here for that.
Thanks to cedric for reporting.
This hasn't been used for a while. Since we are going to break Eo a bit anyway
it's a good opportunity to drop this.
This may cause a slight performance issues with legacy events, such as
smart callbacks. This shouldn't really be a problem as we've migrated away from
them. If it does, we need to migrate the remaining parts. Only relevant
for callbacks that are added before the classes are created, which
shouldn't be possible except for smart, only for old evas callbacks.
Scenario:
- Same signal/function/data registered twice on e.g mouse_down
- On mouse_down, register mouse_move and mouse_up
- On mouse_up, unregister mouse_move
Result: mouse_move still invoked after mouse_up
Reason:
- When the mouse_move callback deletion is required, the cb is
flagged as deleted but is not freed as walking_list blocks.
- When the second (and same) has to be deleted, it will try to delete
the first again because the delete_me flag is not checked.
This patch fixes it by checking the delete_me flag when determining the
candidate.
@fix
This should not happen. Objects with parents must have their parents
unset before they reach refcount == 0. That's because the parent is the
one holding the refcount. This means that if we get to the destructor
(object is deleted) while a parent is still set, we have an error
scenario.
After this change, parent_set assigns a ref, so for example:
obj = eo_add(CLASS, parent); /* Ref is 1 */
eo_do(obj, eo_parent_set(parent2)); /* Ref is 1 */
eo_ref(obj); /* Ref is 2 */
eo_do(obj, eo_parent_set(NULL)); /* Ref is 1, giving the ref to NULL */
eo_do(obj, eo_parent_set(parent)); /* Ref is 1 */
This is following a discussion on the ML about commit
8689d54471.
@feature
optimization
xrefs keep lists of objects references. children are already in a list.
why keep both? lots of extra memory used for no value when debug is on
(pretty much most of the time).
this follows on from cbc1a217bf as this
code was correct, but was then causing bugs due to children staying in
their parent lists. this should never have happened and this is really
bad. this fixes this and ensures children on destruction are gone from
their parent lists.
@fix
it is possible that a destructor/parent_set override or function could
go modifying the children list of objects in a parent, this the
EINA_LIST_FREE may actually miss objects in the process since within
the "free" func the list may have been altered etc.
@fix
This was not really useful and against the Eolian guidelines.
While I promised I won't break things until the 27th, I was ill
(still am), so I'm giving myself a 1 day pass. :P
This is another cleanup in perparation for the Eo stable release.
This is no longer needed thanks to the proper error reporting with
eo_constructor()'s new return value.
The finalizer change cleans it up a bit so it catches more cases/issues.
This also means that the finalizer cleans up the object in all cases,
and not only some.
@feature.
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
This affects eo_do() and eo_add() that used to use the ({}) GCCism.
Following a discussion with Peter de Ridder after my talk at FOSDEM,
we've decided to reopen the GCCism (works with other gcc compatible
compilers like clang and intelc) discussion, and after a bit of back and
forth it was decided to make things more portable, at the cost of ease
of use.
For example:
if (eo_do(obj, visible_get()))
is no longer allowed, the portable alternative
Eina_Bool tmp;
if (eo_do_ret(obj, tmp, visible_get()))
is to be used instead.
However:
eo_do(obj, a = a_get(), b = b_get(), bool_set(!bool_get))
are still allowed and OK.
eo_do(obj, if (a_get()) return;);
is no longer allowed, but:
eo_do(obj, if (a_get()) something());
is still allowed.
For clarity, this commit only incorporates the Eo changes, and not the
EFL changes to make the efl conform with this change.
Thanks again to Peter de Ridder for triggering this important discussion
which led to this change.
For some reason, they were normal functions instead of eo functions,
which makes them harder to bind, less safe, and just wrong.
This commit fixes that.
This enables checking if an object is being created, or has already been
finalized. This is useful in functions that you want to allow
only during the creation phase (i.e inside the eo_add()).
This function lets you hook at the end of eo_add and override it for a
class. This is essentially the first step towards killing custom
constructors. Instead of having a custom constructor, you should just
do:
eo_add(CLASS, parent, a_set(3), b_set("eou"));
eo_constructor is called at the beginning for pre-init things.
eo_finalize is called at the end, for actually finalizing and doing
things. This cleans up the API and possibly saves a lot of things that
would have been stupid and slow in the past, like loading an elm widget
with an existing theme, and then changing the theme.
** This breaks Eo ABI, please recompile elementary and everything else that
creates eo objects.
@feature
Coverity found the issue, but it's an issue we've already fixed in the
past. I don't know how it got lost, but it seems like someone did a bad
merge. Probably when migrating to Eo2.
This reverts commit 831c20464d.
bug T569 still shows that we have cases where, during e shutdown, we
still get eo_data_scope_get() return NULL for a parent object.
whatever this is, segfaulting is much worse than protecting and
marching on. so protect
This is an extension to raster's 0355a6a296
(eo - fix _parent_set in base clase when old_parent_pd is NULL).
I also added an error message in case this check fails.
This reverts commit ee1b0833ed
I did it manually because the code changed too much.
We actually want this type, it makes things more clear and easier to
understand.
These functions let you pass an array of callbacks instead of just one.
It's more memory efficient to use this if you just add a bulk of events
on the same object.
This commits breaks ABI, and breaks API of the EO_EV_CALLBACK_ADD/DEL
signals (the event info passed).
From now, classes implementing the Eo function with id
EO_BASE_SUB_ID_DBG_INFO_GET will be able to show in Clouseau their own
specific information.
Information contents is controlled by the class itself and no more
by Clouseau. Basic types and lists are supported..
Signed-off-by: Aharon Hillel <a.hillel@samsung.com>
SVN revision: 83410
Tom Hacohen
Cedric Bail
Carsten Haitzler
Daniel Kolesa
Marcel Hollerbach
Daniel Zaoui
Jean-Philippe Andre
Chris Michael
Jérémy Zurcher
Cedric BAIL
Lukasz Stanislawski
Cedric Bail
Daniel Zaoui
Daniel Willmann
Aharon Hillel
Vincent Torri