This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
so smart object bounding box wasnt updated properly in several other
cases. fix those other cases too by dirtying bounding box region.
this continues on from:
f6b3c3156125d77bc1d29f0fd66ab8
this fixes T4017
@fix
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.
Note: Only two modes are supported (blend and copy).
The Efl.Gfx and Evas enums were different. All other values
were not supported. For legacy compatibility (since GL engine
actually implements some kind of support for all operations),
render_op_set() should still work fine, even though it's not
recommended, and won't work anymore with EO API.
This is a horrible API used for internal optimizations. Which
may or may not be partly broken anyway.
We can do better, in the future. Let's not expose this kind
of API.
Now called "hint_min", not sure if it's the proper name for it.
At first I wanted to reuse the request size hint instead of
adding a new hint, but doing that would break Terminology
or any app that already used size_hint_request.
One problem with hint_request is that the legacy function
already exists but its support is practically not implemented.
@feature
Still not sure about which keyword is the best to use here,
but anyway, it's a protected function so users should realize
it's probably not what they want.
This includes:
- align
- min (now content_min)
- request
- max
- padding (now margin)
- weight
This does NOT include:
- display mode (compress, expand... a hint used by naviframe only).
Problem:
- edje aspect ratio is defined by 1 enum and 2 double (min, max)
- window aspect ratio is defined by only 1 double
- evas object aspect ratio is defined by 1 enum and 2 ints (w, h)
Which one is the best interface? Are min/max a better option?
Also, not sure how to call the enum...
So, I was stupid. I was relying on legacy callbacks to
trigger eo events, which means that only when a legacy
callback was registered would my new eo events be triggered.
Instead, I can pass the eo event desc & info whenever
calling evas_object_event_callback_call().
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.
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.
if an object iot reffed or not hide on del. it should have been this
way before eo. eoifications i think messed a few things up.
this does bring up an issue... in eo we have no way to explicitly do
stuff on eo_del regardless of references at the time. this needs to be
solved.
@fix
This replaces standard Evas_Object_Image when it is used "normally",
ie. it's an image from a file or from a pixel buffer. All other APIs
(proxy, snapshot, 3d, gl, ...) are disabled on this object.
Also, reduce number of failing calls when the object is not a legacy
object, but a legacy function is called. This is because a lot of
image APIs are called internally using the legacy APIs, often in
order to reset the state of the image object (eg. set file to NULL,
etc...)
It has been decided that we would not use any namespace for interface
and they will sit in efl main namespace.
This patch doesn't correct the naming of the event has we don't have a
prefix for event. We do still have EFL_ANIMATOR_EVENT_ANIMATOR_TICK,
instead of a nicer EFL_EVENT_ANIMATOR_TICK.
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.
The migration scripts breaks with some weird cases, here I manually
migrated some parts, and just removed the eo_do from others without
actually migrating (so I could deal with that later).
This give a constant improvement of 2% over a total benchmark run while scrolling
genlist. This benchmark included setup and destruction of the scene, so under
estimate the cost of the callback emit.
Use delete callback instead of direct call to clip_unset,
which lets us know that clip_unset() is called during the
clipper's deletion, as opposed to a simple call.
We can then make sure that the previous object state does
not point to invalid data anymore.
Here is a scenario that could have crashed:
- load and show an edje object, hide it
- change its theme or style
- show it again
@fix