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
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
Greatly reduce code complexity while providing better support, at
least according to @netstar efl_net_dialer_http works better than
traditional ecore_con_url on BSD.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
now that it's runtime dlopen'ed etc. ecore-con "always" has url
support via curl so ecore-file needs to assume that this can always
work and this just use ecore-con-url anyway.