Small patch to deprecate Ecore_Drm. This patch also adds a configure
option to enable ecore_drm for older code. This option is disabled by
default, so must be explicitly specified during build.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
For ecore_evas drm engine(s), disable setting of
ecore_event_window_direct_callback as this Completely Breaks all input
when running Enlightenment Wayland.
NB: This can likely be re-enabled at some point, when the jpeg
breakage is over ;)
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This adds a few classes, in particular Efl.Event and Efl.Event.Point
which are used as the event info for all pointer (mouse, multi) call
Using an eo object as event info will allow for future extensions
really easily. We don't need to expose any of the internals, also
a single type can be used for all pointer events.
Still TODO:
- Keyboard events (urgent)
- Axis / Joystick events (needs porting from Tizen)
- Gestures support (probably later)
- Event feeding from app side (manual feed)
Not going to be ported to EO:
- Hold API and hold event. Seems barely used.
The new APIs are not very much tested at this point, and rely on the
old legacy event system. The most important thing right now is to
ensure that nothing was broken so far. Unfortunately I can only do
this much testing myself...
Merge branch 'devs/jpeg/work'
If on_hold or on_scroll is set in an eo callback, the subsequent
calls to the legacy callbacks will also have this flag set.
Inversely the legacy callbacks should affect all subsequent eo
callbacks.
Note: those are just indicative flags.
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.
Chris Michael
Stefan Schmidt
Jean-Philippe Andre
Ji-Youn Park
Carsten Haitzler
Andy Williams
Felipe Magno de Almeida
Jaeun Choi
godly.talias
junsu choi
Jaehyun Cho
Jaehwan Kim