so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
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.
this class is a giant FIXME for anyone looking to do refactoring work.
the only reason it seems to exist is to provide wrappers around
efl.gfx functions and provide screen position adjustments--something
which isn't even viable under wayland
note that a test was removed here due to the corresponding method being
removed
Summary:
For example, the widget type of elm_button was "Elm_Button".
But, the object which is created by elm_button_add() will
return its widget type "Efl.Ui.Button_Legacy".
It is not legacy name. It should be fixed to return "Elm_Button".
I don't know when but eolian start to make class name with ".".
So, it should be converted to "_" for all widgets.
@fix
Test Plan:
All test cases are included in this patch.
Run "make check"
Reviewers: raster, cedric, jpeg, taxi2se
Reviewed By: cedric
Subscribers: taxi2se, woohyun
Differential Revision: https://phab.enlightenment.org/D5782
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
focus_user and focus_object are similar classes. by merging them into
one mixin, we can maintain consistency.
Test Plan: make check
Reviewers: bu5hm4n
Subscribers: cedric, Jaehyun_Cho, woohyun, jpeg
Differential Revision: https://phab.enlightenment.org/D5734
The new calculation mechanism does not only look into the exact
directions up,right,down,left of a node, it also now checks the sectors,
bound by: x < node.x, x > node.max_x, y < node.y, y > node.max_y.
ref T6453
Summary:
Added some guards to avoid redefinition of functions.
Partially fixes T5866, as there is still the question whether we should
test internal functions or not, as stated by jpeg in the comments.
Reviewers: vtorri, felipealmeida, jpeg, cedric
Reviewed By: cedric
Subscribers: jenkins, cedric
Maniphest Tasks: T5866
Differential Revision: https://phab.enlightenment.org/D5521
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
elementary_config.h should not even exist. It's been hijacked as a
private header for elementary, but all "real" configuration is stored in
efl's main config.h now.
If you call focus_set(m, o) where o is a logical child, then the focus
will go to any none logical child of o, or if there is nothing in the
children of o, then the focus will remain on the now focused element.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
Carsten Haitzler
Mike Blumenkrantz
Marcel Hollerbach
Youngbok Shin
Lauro Moura
Yeongjong Lee
Andy Williams
Amitesh Singh
Sungtaek Hong
Lukasz Stanislawski
Jean-Philippe Andre
Lukasz Stanislawski
Marcel Hollerbach
Stefan Schmidt