unload is a crucial method for classes that implement load, as this is
the method which is called during e.g., efl_file_simple_load() when
a new file is specified in order to destroy the previous object data
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9786
Currently we do 2 pass updation. first we scan through all the styles
and check if they have text_style which matches the test_style we need to update
then we mark them dirty. then we call style_all_update() to go through the list
again and update those styles.
By combining them both in a single function we avoid scanning through the whole
list again.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9639
Obviously previous edje object file set would try reload file
even though the file is already loaded.
This brings different result if the file data has been modified or changed.
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8129
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8128
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D8107
Summary:
the previous implementation/api had a number of issues:
* "file" property contained both "file" and "key" values
- also performed file loading operation
* "load_error" property which was specific to image objects
* no methods for controlling file loading/unloading
this patch attempts the following changes:
* split "file" property into "file" and "key" properties
- also remove "key" from existing "mmap" property
* remove "load_error"
* directly return error codes from operations
* add "load" and "unload" methods for directly controlling load state
* add implicit file loading if file/mmap is set during construction
* rewrite all efl.file implementations to move file loading into load() method
* rewrite all usage of efl.file api based on these changes
* add C extension functions to mimic previous behavior
ref T7577
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: vitor.sousa, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7577
Differential Revision: https://phab.enlightenment.org/D8018
Summary:
Eolian adds a per-class BETA guard (like EFL_UI_WIN_BETA) to any method tagged
as @beta. This means that any app (and the EFL code) wanting to use BETA features
has to enable them class by class, which is cumbersome.
This commit replaces the individual guards with the global EFL_BETA_API_SUPPORT
guard, so apps only need to define one symbol to access BETA features.
Any usage of the per-class guards has been removed from the EFL code and examples.
When building EFL the global guard is defined by configure, so all EFL methods
already have access to BETA API.
Efl_Core.h and Efl_Ui.h no longer define EFL_BETA_API_SUPPORT. Apps wanting to
use BETA API have to define this symbol before including any EFL header
(It has been added to the examples requiring it).
Test Plan:
make && make check && make examples still work, but there's a lot less #defines
in the code
Reviewers: zmike, bu5hm4n, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T6788
Differential Revision: https://phab.enlightenment.org/D7924
Summary:
edje_edit_object_add
edje_object_add
emotion_object_add
evas_object_xxx_add
These APIs had allowed to set parent to EFL_CANVAS_OBJECT(Evas_Object) before
8bb11a17. we should call evas_find before safety check for backward compatibility.
Test Plan:
win = elm_win_add(NULL, "main", ELM_WIN_BASIC);
1. `rect = evas_object_rectangle_add(evas_object_evas_get(win));`
2. `rect = evas_object_rectangle_add(win);`
Check that 1. and 2. works.
Reviewers: Hermet, zmike
Reviewed By: Hermet
Subscribers: cedric, #reviewers, CHAN, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6909
Summary:
A object that is not evas class shouldn't use evas_find. it may occurs segfault.
ref c2e8b492b1
Test Plan:
Evas *evas = evas_new();
evas_free(evas);
evas_object_line_add(evas);
Check weather there is segfault.
Reviewers: Hermet, raster, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6816
Summary:
these objects are destroyed when invalidate is called as a result of the
evas smart object class destroying the smart object at this time
ref D6222
Reviewers: bu5hm4n, devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6540
Summary:
a swallowed child is per doc not deleted when the edje is deleted.
After the call to invalidate is finished all children will loose theire
parents and also be invalidated. However, in the efl_invalidate call,
the event EVAS_CALLBACK_DEL is issued, so this is the right spot. As in
legacy the swallows are in place when the EVAS_CALLBACK_DEL event is
issued.
Reviewers: cedric, raster, JackDanielZ, zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6222
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
The interface efl_part_get should not be directly called from C, but the efl_part
wrapper should. It rely on efl_noref to properly destroy the object. Binding can
control the lifecycle of the reference the way they want by either calling the
wrapper or efl_part_get directly. It also means that the ugly ___efl_auto_unref_set
doesn't need to be exposed outside of EFL anymore.
Differential Revision: https://phab.enlightenment.org/D6098
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
This fixes some of the warnings generated by calling functions on NULL
objects. One of the main remaining points is to avoid unwanted warnings
on non-existing parts.
Ref T6326
Call provider_find on the loop (or basically any object) with the
color/text/size class interface instead, to find it. The main loop is
the main holder of those objects.
Note: This makes use of provider_find instead of direct access to the
variable, in order to self-test the code. In theory release builds will
not do this and user directly the variable.
This isn't meant to be installed. The canvas API in EO is based around
the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is
not EO (eg: ecore_evas, evas, ...)
Note: evas_canvas3d is the last remaining thing that is installed along
EO files, but those are all beta APIs.
Simply pass in the strbuf and don't expect the callee to own it. This
makes things simpler and safer (it'll crash only if the callee frees
said strbuf, and shouldn't leak). efl_ebug_name is new in the upcoming
release, EFL 1.21.
Realised this after talking with Amitesh. Thanks.
See 999dbd9764
And c4769ff898
Those APIs can then be used by Elm.Layout, hopefully
simplifying the API.
I wonder if the APIs should be prefixed "calc_" (as is)
or "layout_calc_". The extra "layout_" prefix would make
it common with other layout APIs (eg. signals, data,
size min/max, ...).
Ref T5315
This is really only a demonstration of what kind of information
we can print with efl_debug_name_get(). Hopefully this can help
debugging with printf/ERR logs and even help with live debugging
inside gdb.
This shouldn't be used for other purposes than debugging, as the
exact string format is not defined.
@feature
Most of the values were the same, with edje having just a couple
more error codes.
Not entirely sure the prefix Efl.Image is correct for this type.
Maybe just Efl.Load.Error?
After a long search I found that fileselector was not calling
super.group_del on deletion, leading to the use of dangling pointers.
So let's verify that group_del is properly called.
See T4598
if its a file downloading (to a tmp location) or a zip/tar/whatever
file being extracted also to a tmp location and that tmp file needs to
be removed after ...you need to keep the obj around to know when to
delete the file. this makes the keeping optional and you query if the
vpath obj is meant to be kept or not. if it's not it's safe to del
immediately.
this cuts down 1 obj per image obj/edje obj when generally unused.
save some mem.