We now use eo_do() and EFL_CANVAS_SCENE3D_CLASS macro to create viewport
Reviewers: raster, Hermet, cedric
Subscribers: jpeg, artem.popov
Differential Revision: https://phab.enlightenment.org/D4163
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Coverity reports that 'text' here is a null pointer dereference so
check for valid 'text' variable before trying to use it.
Fixes Coverity CID1267490
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: check if the size of scene is bigger than 0x0 and build 3D scene in the edje_player in this case and use "opengl_x11"
Reviewers: Hermet, jpeg, cedric
Subscribers: NikaWhite, Oleksander, artem.popov, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4041
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
this should cut some memory used by edje by using smaller types like
shorts instead of ints where we just dont need a full int range and
short will do, and re-ordering in memory data soit packs better when
accoutning for alignment
Summary: Creation of scene and root node in edje-3d with all 3D-parts of edje object. Add some new methods to edje_util.c
Reviewers: raster, Hermet, jpeg, cedric
Reviewed By: cedric
Subscribers: artem.popov
Differential Revision: https://phab.enlightenment.org/D3963
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
This should now fix the part API usage once and for all.
EFL should have no part name in any of its APIs beyond
the Efl.Part interface.
Part proxy objects (may be real objects) have a lifetime
of only one function call, in a fashion similar to eo_super.
@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.
Summary:
According to D3710 new field "camera" in edc was added for IMAGE parts.
It is the name of the CAMERA part to set its viewport as a source of image if no image name is given.
Reviewers: raster, Hermet, cedric
Reviewed By: cedric
Subscribers: jpeg, artem.popov
Differential Revision: https://phab.enlightenment.org/D3777
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
This fixes on top of 49a27688b1, which
assumed somehow that table items had names, although that
might not be the case. In my situation, name = NULL and there
was a crash everytime I clicked on the clock widget.
If the table item has a name, posible case when item name length, with
index, will be 12. The 12 is predefined length for box index.
Quote Cedric
In a box, the index is one dimension, one int, thus the length
of it (from int to string) will always fit inside 12 bytes. That's
where this 12 comes from. That's also how the unique name of that item
is defined.
This commit separate the items name generation by part type, it will be
more correctly.
@fix
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.
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.
Summary: Initiation of Evas Objects and creation of nodes for new part types in Edje.
Reviewers: cedric, raster, Hermet
Subscribers: jpeg, artem.popov
Differential Revision: https://phab.enlightenment.org/D3665
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
The "color_tree" block contains a list of one or more "node" blocks.
A "node" block consists of its own color class name and the list of child
color classes. At runtime, parent color class will be referred instead,
if child color class is set to part but its color values are not defined.
Reviewers: raster, Jaehyun_Cho, jpeg, cedric
Reviewed By: cedric
Subscribers: cedric, kimcinoo
Differential Revision: https://phab.enlightenment.org/D3606
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This is necessary for backward compatibility still I am thinking of displaying a warning for this
use case and request people to update there work and drop that feature in the future (In a year
maybe from now). Elementary doesn't need this as it depends on Ecore_Evas.
Edje_Part can change its min or max size in code level with
size_class.
Differential Revision: https://phab.enlightenment.org/D3329
PS: Manual commit, arc refused to work...
@feature
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
evas_object_clipees_has is far cheaper than evas_object_clipees_get in case of checking if
clipees exist or not. This should improve the performance in case of large set of clipees.
@fix
Without that, the image has no fill information. Fill properties
may need to be added to SNAPHOT parts but the default behaviour
should make sense. Before this patch you just get a black rectangle.
Considering how image filters currently work, marking snapshots
as filled by default is not the best solution (need padding_set(0)
to render nicely).
This is now like the other embedded scripts, where a verbatim
string is parsed. The syntax is now:
filters {
filter {
name: "filter0";
file: "filter.lua";
}
filter {
name: "filter1";
script {
blend {}
}
}
filter.file: "file.lua"; // name is "file.lua"
}
Thanks @raster for the quick review.
Deep down internally there was already a name, but no API could
really set it properly.
Here Edje will set the name of the filter based on the part name
or the data item name if relevant.
Use the file data {item, file} block to embed filters code.
It can become especially useful to keep the filters as separated
Lua files, that will be embedded in the final edj file.
@feature