Commit Graph

162 Commits

Author SHA1 Message Date
Jean-Philippe Andre 7bf8da2baa evas: Rename Evas.Object to Efl.Canvas.Object
One step closer to make the EO inheritance tree look like
it's all Efl.
2016-06-21 14:35:19 +09:00
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 b2355d7da3 Evas: Rename Selectable_Interface to Efl.Ui.Selectable 2016-06-10 18:06:15 +09:00
Jean-Philippe Andre 31c4fd1f7c Evas: Rename Scrollable_Interface to Efl.Ui.Scrollable 2016-06-10 18:06:15 +09:00
Jean-Philippe Andre d67171940f Evas: Rename Draggable_Interface to Efl.Ui.Draggable 2016-06-10 18:06:10 +09:00
Jean-Philippe Andre e691de04be Evas: Rename Clickable_Interface to Efl.Ui.Clickable
Event prefix is efl_ui:
 EFL_UI_EVENT_CLICKED
 EFL_UI_EVENT_CLICKED_DOUBLE
 ...

The event prefix could be reduced to efl but I personally
prefer with UI.
2016-06-10 17:33:53 +09: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
godly.talias afb4a194a8 Added feature to bring focused item to viewport on click
Summary:
Currently when an item in gengrid is focused and if it is scrolled
off the viewport halfly and if it user clicks on it, it won't be
scrolled into viewport. Only non-focused items will be scrolled into
viewport when clicked.

Test Plan:
elementary_test -> Gengrid focus -> Click an item ->
           Scroll it little bit out of viewport -> Click again

Reviewers: prince.dubey, shilpasingh, cedric, raster, SanghyeonLee

Subscribers: seoz, rajeshps, govi, jpeg

Differential Revision: https://phab.enlightenment.org/D3977
2016-05-30 14:39:37 +09: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
Cedric BAIL c2a1c49ab2 elementary: move all legacy files to their expected new location. 2016-03-23 13:24:41 -07:00