Commit Graph

11 Commits

Author SHA1 Message Date
Jean-Philippe Andre 52f9220b3f Evas: Rename smart object into Efl.Canvas.Group 2016-06-17 19:32:43 +09:00
Jean-Philippe Andre 42b63f5507 Evas: Add smart_ prefix to all smart functions (eo)
This is a first step at separating legacy smart
object features away from standard efl interfaces.
2016-06-17 19:25:48 +09:00
Jean-Philippe Andre 9a052a740d Evas: Move smart_callbacks_descriptions to legacy 2016-06-17 19:25:47 +09:00
Jean-Philippe Andre a4701ea969 elm: Partially revert "elementary: avoid random memory access."
This reverts commit ac5a0b7e79.

I added assert(pd == sd) in the modified code and couldn't find
anything suspicious. The proper class is used in eo_data_scope_get().
I also can't find a crash or a bug currently in hover. I know there
was a problem earlier, but that was fixed in 3092e08a83.

Now, if there is still a problem, we should check it carefully.
Pinging @cedric
2016-06-03 15:29:17 +09:00
Cedric BAIL ac5a0b7e79 elementary: avoid random memory access.
It seems that this content_get function are not getting the data pointer
they expect at all.
2016-06-02 17:20:16 -07:00
Tom Hacohen a6a2338962 Revert "Eo: Remove eo_del() and make eo_unref() the replacement."
This reverts commit 546ff7bbba.

It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.

We would have an issue with references and objects being freed too soon
and in general, issue with the references.

Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.

eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
2016-06-01 13:33:21 +01:00
Jean-Philippe Andre 99924852ab Efl: Remove part name in Efl.Container (use Efl.Part)
This touches Edje and also Elementary where part names are used.
This commit blew up in size since now all content part APIs
(get, set, unset) require to use Efl.Part instead.

This is a big refactoring commit, but no logic should
have been changed. Fingers crossed.
2016-05-26 19:55:50 +09:00
Daniel Kolesa 7782c0bcb9 eolian: add event_prefix and have classes follow that or eo_prefix by default
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
2016-05-17 17:50:43 +01:00
Tom Hacohen 546ff7bbba Eo: Remove eo_del() and make eo_unref() the replacement.
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.
2016-05-17 16:23:23 +01:00
Jean-Philippe Andre 902950018b Efl: Introduce Efl.Container and unify APIs
This removes Efl.Pack_Named which had a terrible name,
removes Elm.Container which should have been renamed
Efl.Ui.Container anyway, and introduces an interface
Efl.Container instead.

The hierarchy tree is now changed as objects don't inherit
from Efl.Container (it's an interface, not a regular class)
but only implement it. Obviously it is very easy to
reintroduce an Efl.Ui.Container parent class if we need it,
but I guess it should have some actual logic. It's basically
part of what Elm.Widget already does.

Some function names have been modified to look better in C
with the efl_content prefix.

@feature
2016-04-26 11:36:23 +09:00
Cedric BAIL c2a1c49ab2 elementary: move all legacy files to their expected new location. 2016-03-23 13:24:41 -07:00