This allows apps to set the objects min size with hint_min,
while letting the rest of EFL define the minimum size with
rstricted_min.
I don't like the property names much...
Now called "hint_min", not sure if it's the proper name for it.
At first I wanted to reuse the request size hint instead of
adding a new hint, but doing that would break Terminology
or any app that already used size_hint_request.
One problem with hint_request is that the legacy function
already exists but its support is practically not implemented.
@feature
Still not sure about which keyword is the best to use here,
but anyway, it's a protected function so users should realize
it's probably not what they want.
This includes:
- align
- min (now content_min)
- request
- max
- padding (now margin)
- weight
This does NOT include:
- display mode (compress, expand... a hint used by naviframe only).
Problem:
- edje aspect ratio is defined by 1 enum and 2 double (min, max)
- window aspect ratio is defined by only 1 double
- evas object aspect ratio is defined by 1 enum and 2 ints (w, h)
Which one is the best interface? Are min/max a better option?
Also, not sure how to call the enum...
UP/DOWN arrows were having effects on both focus and entry cursor
moves. This was due to an invalid propagation of the changes to
event_flags (on_hold).
Fixes T3845
Summary:
* pointer.button is DATA32 which is unsigned, so this changes the
definition of pointer_button_down_mask accordingly.
* Avoids UB in mask generation:
lib/evas/canvas/evas_events.c:1348:37: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4019
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Implemented interface Efl.Gfx.Buffer functions bufer_map/unmap for Efl.Canvas3D.Scene.
Added function e3d_drawable_texture_rendered_pixels_get to module evas_gl_3d
to getting pixels from FBO. Added wrappers for functions
e3d_drawable_texture_rendered_pixels_get and e3d_drawable_texture_id_get
to have possibility call it through engine functions.
Reviewers: cedric, Hermet, raster, jpeg
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3978
So... I had issues with evas-fb engine which was massively leaking,
one image per frame.
After investigating a bit with @cedric on IRC, the reference count
of the cache entries was always 2 before the engine dropped.
So, for each frame with an animation, we could never drop a cache
entry, leading to a trumendous amount of memory leaking.
Now for non-async rendering, we copy the behaviour of
evas_render_pipe_wakeup() which is called in async-mode,
and actually drops a reference in the cache entry.
Fixes T3763
This does:
1. Forward keyboard events from evas to win
2. Allow feeding external input events
Input events can be faked by apps by simply forging
eo objects of the proper type (key or pointer evt) and
calling eo_event_callback_call().
Such events will be forwarded to the internal Evas, and
some bool flags prevent infinite refeeding loops.
efl_event_dup() returns fake events for this to work.
@feature
This lets me narrow down the remaining cases of pointers across the EFL.
The void pointers will later need to be reevaluated on per-case basis and
replaced appropriately where possible/feasible.
So, I was stupid. I was relying on legacy callbacks to
trigger eo events, which means that only when a legacy
callback was registered would my new eo events be triggered.
Instead, I can pass the eo event desc & info whenever
calling evas_object_event_callback_call().
This code was written when eo_del() was removed and eo_unref() was the
recommended practice. Since we added eo_del() back we now need to adjust
this new code accordingly.
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
Summary:
- added is_active property in Evas_Key_Grab.
- Evas key down and key up events transferred to active grabs only.
- If evas grabs has a exclusive grab, other grabs will be deactivated.
- If a exclusive grab is ungrabbed, remained grabs will be activated.
Reviewers: jypark
Reviewed By: jypark
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3996
Summary:
We did the same for evas_canvas3d_scene_pick(see c850cc0d80),
but forget for evas_canvas3d_scene_exist.
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3973
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
It is logically break cycle in case object is found. In case need pick all objects
that lay in screen ray, we should use evas_canvas3d_scene_pick_member_list_get
function.
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3975
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
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).
Complex types (i.e. list, array, hash, accessor etc.) now do not require
pointers with them anymore (the pointer is implied) and the same goes for
class handles. Eolian now explicitly disallows creating pointers to these
as well. This is the first part of the work to remove pointers from Eolian
completely, with the goal of simplifying the DSL (higher level) and therefore
making it easier for bindings (as well as easier API usage).
@feature
Jean-Philippe Andre
Benjamin Jacobs
Oleksandr Shcherbina
Jean Guyomarc'h
Daniel Kolesa
Tom Hacohen
JEONGHYUN YUN
Jean Guyomarc'h
Carsten Haitzler