This is going back to the same idea as legacy. We will have
events such as:
- move
- down
- up
- in
- out
- wheel
- cancel ("new" - very rare)
Now the question is whether/how we should divide "multi" events
which start from the 2nd finger from standard mouse events. The first
multitouch finger should by default look like a mouse event.
This moves Efl.Pointer.Event back to Evas. Originally I wanted
to share this class with Ecore but eventually I didn't need to
do so, since only ecore_evas (which depends on evas) really needs
access to these.
The internal data struct is not moved out of efl (yet?)
This continues the work started in the previous commit:
forward full event info (Efl_Pointer_Event) from evas to
the upper layers.
This also includes more support for IN and OUT.
This is still VERY experimental and not fully done yet.
All other pointer events need to be sent as well.
The legacy event system is used as a transportation mechanism,
as it is too hard to change the logic. This only adds an extra
eo event in case of move. Obviously for performance we might
want to listen to callback_add,del but that's an optimization
for later.
The whole point of sending those pointer events is to carry more
information than can be sent over legacy evas events, and unify
the events in a common format.
This whole input system is a massive mess. It looks like spaghetti.
Long live the giant flying monster.
This commit changes how some events are propagated in X.
Before:
ecore_x -> evas_event -> evas
After:
ecore_x -> ecore_input_evas -> ecore_evas -> evas_event -> evas
There are still inconsistencies between events and between X and WL,
but ecore_evas should be used for all events since it rotates the
inputs.
This way, ecore sends eo events to evas, which can then
be listened to by other clients (FIXME: the events will
need to be propagated from evas to the elm window).
Current support:
- mouse/multi down
- mouse/multi up
- mouse/multi move
- mouse wheel
Since the direct input event callback returns true if the
event has been processed, we can easily support legacy and
progressively implement full support for eo input events.
This object is the data carried over in an event data pointer.
The private data should be accessible by Ecore and Evas, but
not externally. This means we should be able to easily extend
the feature set, adding more and more information, without
breaking API / ABI.
Also, this should allow applications to create fake input
events easily without exposing our internal structures, or
functions with more and more parameters (such as feed multi).
This is only a storage class, shouldn't contain any logic.
In the future, some logic may be added for gestures support
for instance, or input smoothing / resampling (eg. if input
frequency is 90Hz and screen refresh rate is 60Hz).
The aim is to replace:
- Evas_Event_Mouse_Xxx
- Evas_Event_Multi_Xxx
- Ecore_Event_Mouse_Xxx
We might want to also support Axis, Gestures, etc... with the
same model or even same storage class.
So, this is not a very clean solution, but this mostly
makes Evas_Device an Eo object of class Efl.Input.Device.
Since evas_device relies on some Evas knowledge (evas
callbacks, canvas private data), it can't be fully moved
to lib/efl/.
Making the input device an interface rather than a class
was also not a great solution, as the goal is to share
the data structure around EFL internals (Ecore and Evas).
Test wasn't enabled when modifications to function prototypes to
eio_job_file_xattr_list and eio_job_file_xattr properties were
made, so it got pushed inadvertidly without the necessary
changes to user code.
previously, elm_image refered to align values
set by evas_object_size_hint_align_set function
to position the internal image inside an image object.
size hint value is for positioning the image object inside its container object,
so the previous code is inappropriate.
this commit adds 'align' property for positioning the internal image.
this is an args event. right now we don't use it, but this should be
done by some of the setup/init of an app and then produce an args
event. the idea would be that this can be used by single-instance apps
like web browsers, terminology to treat launch as an event.
Summary:
Currently when an item in gengrid is focused and if it is scrolled
off the viewport halfly and if it user clicks on it, it won't be
scrolled into viewport. Only non-focused items will be scrolled into
viewport when clicked.
Test Plan:
elementary_test -> Gengrid focus -> Click an item ->
Scroll it little bit out of viewport -> Click again
Reviewers: prince.dubey, shilpasingh, cedric, raster, SanghyeonLee
Subscribers: seoz, rajeshps, govi, jpeg
Differential Revision: https://phab.enlightenment.org/D3977
Previously, preserved content was shown unexpectedly after its naviframe
item was popped because the preserved content was not removed but was
unset from its naviframe item.
Since popped naviframe item becomes hidden on the screen, the preserved
content of the popped naviframe item should become hidden by default as
well.
So, I was storing a single "sd" pointer (class private data)
but using it in two different places, ie. as if it were two
different classes. Crashes happened, complaints were heard.
See T3714.
This fixes T3714
Efl.Part uses a basic inheritance for layout objects, but somehow
this completely falls apart when the child class overrides all
the functions. Weird. I'll check that more.
Summary:
When the widget is unset from any container, a parent of the widget
doesn't exist. So we should set its parent to the top object.
But if we just set sd->parent, the parent can not find the widget as a
child. So the container widgets set the parent-child relation when
sub object is unset.
This commit is related to 0822ad2195.
@fix
Test Plan:
Check this issue.
https://phab.enlightenment.org/D3855
The unset widget don't added any widget as child.
So when it set scale, the widget can not reload the thmeme.
Reviewers: raster, cedric, Hermet, reutskiy.v.v
Reviewed By: Hermet, reutskiy.v.v
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3957
Conflicts:
src/lib/elementary/elm_mapbuf.c
This was actually difficult...
Mac OS X can use addr2line (sometimes called gaddr2line in
function of the package managers). However, addr2line does
NOT handle specific cases.
It was therefore necessary to use Mac OS X' own tool: atos,
which gracefully handles all backtraces, including the one
containing objective-c messages or fat archives.
eina_btlog now tests different utilities one by one, and
determines whether it is supported or not.
Fixes T3711
sched_getcpu() is glibc-only, so not portable. Mac OS X
does not have it, and has no obvious replacement function.
This commit will allow future code to test for the existence
of this function, to provide fallbacks instead of making
compilation fail.
Libuwind may not be shipped with a pkg-config file.
It can be distributed on the system, but the autotools
would fail to detect it because it relied only on pkg-config.
We now first check with pkg-config, and then try to compile and
link a program using libuwind to see if it is supported anyway.
This is a first step towards a working eina_log_backtrace on
Mac OS X.