This converts Evas_Axis or Ecore_Axis info arrays into basic
pointer data. Also marks those fields as set. All events need
to properly implement the value_has property (mark all bits
whenever a value is known).
This sets a bit whenever a callback listener is added.
I couldn't get any profiling data easily (too small for
valgrind).
Note: This removes the proper refcounting on the "move"
event listeners. I believe this is not a problem as most times
the move_ref goes to 0, it is because the object is deleted.
Worst case, we just trigger a callback_call with no listeners.
This adds 32 bits to each evas object private data.
This event should not be exposed at all, it's not necessary
anymore, EFL_EVENT_DEL already exists and should be good enough.
This does move the callback call a little bit ealier in the del
process, but at first glance, this shouldn't have any impact.
This moves MULTI events to those new finger event types,
and also sends a finger event for finger 0 (aka the pointer).
NOTE: This may require a separation between a mouse input and
an actual finger touch. To be defined, ie: do we let the app
check the input device info to decide whether the event is
actually the first finger of a multi touch device, or do
we want to send only actual finger events from multi touch
devices only?
@feature
This is getting trickier, as those events have a lot more
side effects and complexity than a simple wheel event...
Some code has been added that should be fixed in the following
commits.
Summary:
Visual position of ellipsis item should be set according to
its bidi direction. But, by setting visual position in same way
as logical position, the end ellipsis could be put opposite side.
Also, start ellipsis must placed on left side of RTL text.
@fix T3187
Test Plan: Test an sample on T3187
Reviewers: tasn, woohyun, herdsman
Subscribers: raster, Blackmole, z-wony, cedric, jpeg, minudf
Maniphest Tasks: T3187
Differential Revision: https://phab.enlightenment.org/D3769
Summary:
We can't assume the given font is same with current fdesc by comparing string.
Since Evas starts to supporting "auto" for language,
the given font string should be parsed once before comparing it.
@fix
Test Plan: N/A
Reviewers: tasn, raster, cedric, herdsman
Subscribers: jpeg, minudf, z-wony, Blackmole, woohyun
Differential Revision: https://phab.enlightenment.org/D4227
Since the new event type is the same for multi and single
touch (finger id is the only difference), multi touch listeners
would get triggered even for single mouse events.
Fixes https://phab.enlightenment.org/T4345
Fixes https://phab.enlightenment.org/T4378
This raises a question though: How do we want to differentiate
between single & multi touch events in the eo interfaces?
The previous patch 1185c40e50 shows how having
two event types for the same thing (key or mouse input events)
was a bad idea. The only guaranteed order of callbacks is the
priority but even that was not enforced (since legacy or eo
style event had to come first).
Fixes T4310
Previously, it was limited to the part block. It was a mistake
and should have been put in the description instead, as this
allows it to change during state transition (like visible, or
proxy_src_visible).
@feature
The new event info being an eo object, it needs to be properly
cleaned. I believe this memleak would not show up much in massif
or other checking tools, as it's a stringshare leak. Also, most
of those event objects will in fact be reused and never deleted.
@fix (backported as c58e293d34)
handle smart member add if the object is invalid withotu crashing.
also don't abort and crash with other invalid states like of smart
object or child is to be deleted, has no layer etc. - continue on
safely without a crash.
@fix
thsi fixes invalid memory access to already freed memory in a parent
call where a child freed it by reference counting the struct to
ensuire it stays alive in the parent func using it.
@fix
if clipped color changed and not object color on image objects, then
the updates could be missed. this also fixes some corner cases where
opaqueness should not count for update deletion too. this bug seems to
have been here a while unnoticed.
fixes T4246
@fix
This affects pointer & key events.
Here's the scenario: in Enventor, an elm_button object
grabs the up & down keys for the autocompletion feature.
But the entry will also listen to up & down to move the
cursor. Moreover, the scroller listens to up & down arrow
keys to scroll around.
So, when calling the new eo event first, the scroller
or the entry would catch it and do some action. In
Enventor, this triggered a hide on the magic anchor
object. Bad, bad.
I fear something will be wrong with this order as well.
Both events (legacy & eo) should be called simultaneously,
following the order & priorities that were set.
This being said, in real life most of EFL internals will
move to the new eo events (right now elm relies on the
new events, but edje doesn't, yet), so any app grabbing a
key probably wants to handle the event before elm. Same
for an app using focus manually.
Fixes T4310
Due to the way the clip geometry calculation changed
(see 25d77bc1d2) to be
based on the bounding box rather than the raw geometry
of smart objects, the internal function
evas_object_is_in_output_rect() now returns true if the
rectangle intersects with that bounding box, even if
it's outside the raw geometry.
This breaks the drop area in E's pager, as it relies on
evas_objects_at_xy_get() to find which objects are at
this point. What I saw on my desktop was that only the
lower 10 or 20 pixels were droppable in the pager,
as maximized windows would have shadows covering the
upper 20 pixels or so.
Arguably objects_at_xy_get could also return all objects
at (x,y) including smart objects that extend beyong their
geometry. This can be added as a flag in the EO API, but
not in the legacy API.
while removing children from a parent smart object, the destruction of
the smart obj encountered childrne with NULL parents. they were in the
child list but had no parent. This was totally odd and unexpected,
thus caused an infinite loop trying to dlete a child that won't be
removed from the list because parent is NULL thus it cna't find the
parent list to remove it from. This works around that and then
complains with an error. The workaround also seems to have encountered
what might be a compiler bug so I prepended to the layer object list
rather than appended. this at leats stops the hang.
@fix
The specific handling for (0.0 <= ellip < 1) doesn't support multi-line cases.
One of the main reasons is that we haven't had the chance to define the wanted
behavior for multi-line.
This is a temporary hack to fix a segfault. The behavior is still undefined,
though.
Fixes T3885.
This is to avoid ERR messages such as "object is not an image!"
that can happen when a legacy image function is called on an
eo image (proxy, 3d, ...) object.
Note: This does not fix any known issue, but it's probably a safer
solution.
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
In elm_image, efl_file_get() was called on a legacy Evas Image
object, which generated an ERR message. This was way too much
noise for something that actually works.
It's best not to call efl_file_get/set API on a legacy
object, but it can be convenient for smooth code transitions
from legacy to pure eo.
Also, add safety to those APIs.
Test case: elm_test genlist dnd, start dragging anything.
ok. so here's the issue at least now. we have eo objects in the canvas
and they have a refcount of 2 user_refcount is 0. the calls stack does
NOT show we are calling callbacks at that time on these objects. they
are not in the backtrace (the canvas is, the objects themselves are
not).
SOMETHING is keeping 2 eo "internal" refs on these objects and i have
no idea what/how/who. it's a royal pain in the butt to find out as the
only way is lots and lots of logging and you get drowned in the
logging...
so what I have now done is a super ugly workaround that detects these
zombie objects that refuse to die and just FORCES them to die when the
evas canvas frees and clears out layers.
ac10a00acc doesn't really cause the
issue, it just brings it out in the open for all to see far more
easily. but something is deeply wrong SOMEWHERE with SOME objects and
our refcounts.
this fixes T4187
so if an img obj had some update regions and was opaque, it didnt del
an update region first before adding the updates, thus possibly
letting update regions pass through the opaque image area
@fix
this fixes over-rendering (where we render the whole image) if it has
a border set. do proper region updates if the image has a border but
is not scaled and the fill is at 0 0 and sams size as the object etc.
etc. so this is simple and doable.
this fixes T4123
this just makes it more obvious where its handling the opaque middle
fill case. see T4123 - i was just reding the code and this seemingly
does the right thing.
This fixes the following ERR message:
ERR<30400>:eo /home/jpeg/e/core/efl/src/lib/eo/eo.c:462 _eo_call_resolve()
in ../src/lib/evas/canvas/efl_event_input.eo.c:3: func 'efl_event_flags_get'
(1483) could not be resolved for class 'Efl_Event_Hold'.
This is an EO-API only fix.
This fixes the following ERR:
ERR<23969>:eo /home/jpeg/e/core/efl/src/lib/eo/eo.c:462
_eo_call_resolve() in ../src/lib/efl/interfaces/efl_event.eo.c:5:
func 'efl_event_instance_get' (1479) could not be resolved for class 'Efl_Event_Hold'.
i don't know for sure if this fixes T4103 but in theory i think it
might given a reading of the backtrace and a guess at what might
happen, so try this fix. it doesn't hurt and can only help.
@fix
This should fix T3309
Snapshot objects are image objects, so the function is_opaque
exists. No need to bypass it. Also, alpha rectangles are not
opaque. Assume that anything with a filter is not opaque.
All of this fixes T3309 but the main point was on snapshot
objects (probably because the only point of a snapshot is
to apply a filter on it).
The cursor position was not set correctly to the respective fnode, causing
annotation to not be applied correctly with text that has more than one
paragraph.
The trivial case of [pos,pos] (i.e. range of length 0) didn't work if there is a
format item in 'pos'.
The condition was fixed to not include such items. The reason it was not
apparent for text items is that these have further handling in the rest of the
code and would've been disposed of.
@fix
Summary:
Font size is scaled according to scale factor.
The linesize, linegap formats also have to be scaled properly.
@fix
Test Plan:
Test cases are included.
Run "make check"
Reviewers: woohyun, Jieun, tasn, herdsman
Reviewed By: tasn
Subscribers: raster, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3688
Summary:
BiDi text is truncated because the way we find the last visual item in text object is wrong.
This patch is similar with _line_native_last_visual_get function in textblock.
Reviewers: cedric, tasn, herdsman
Subscribers: id213sin, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3947
so smart object bounding box wasnt updated properly in several other
cases. fix those other cases too by dirtying bounding box region.
this continues on from:
f6b3c3156125d77bc1d29f0fd66ab8
this fixes T4017
@fix
this is a continuation fix from
25d77bc1d2 and
9f0fd66ab8
this fixes yet more corner cases after the above 2 fixes. our clip
cache tracking code seems to be broken somewhere and not updating - at
least when events are processed so i did ti the slightly slower way
and recursed through clippers to figure it out in this path. it all
works now it seems but it's got a small speed hit. better be right
than a little faster.
@fix
i've fixed almost all the eina init/shutdown pairs to do the right
thing now... except one (ecore_shutdown) with comment inline where
eo_shutdown is not called. if this is called we are in crash land.
this needs further inspection.
Scenario:
smart {
text
proxy -> text, src_invisible
}
proxy -> smart
What we should see:
smart {
(blank)
proxy -> text
}
proxy -> {
(blank)
proxy -> text
}
What we saw:
smart {
(blank)
proxy -> text
}
proxy -> {
text
proxy -> text
}
Solution:
Check in evas render, when we're inside a proxy render, and the
proxy src_invisible flag is on (evas_object_source_visible_set(0),
that we're rendering the object itself to its proxy surface. If not,
it means we're rendering another proxy surface, ie. a parent smart
object's proxy surface.
Still loving evas render.
Fixes T4006.
@fix
Those are marked as EINA_DEPRECATED since they are for legacy only,
and EDC is the preferred method.
Note: these are new in EFL 1.18.
I would rather have not added them as legacy APIs. This patch is
here to align to Tizen which added them by mistake. Also, remove
the "name" argument from filter_program_set as it's not required,
and also not there in Tizen's code base.
Sorry for the mess.
It relies a bit on evas legacy APIs and will only work on
evas objects (Efl.Canvas.Object) for now.
The main difference with Evas_Map is that there is no
separate map object, as the functions apply directly to
any canvas object.
For convenience, most functions will automatically populate
the map if there was no previous map info. While this may
be convenient, the object's size changes still need to
be tracked to update the map info.
Summary:
Some fonts can have weird style and weight value.
If a font has a style name as "medium" and a weight value as "semi-bold",
Evas can't load the font using "font=Somefont:style=Medium".
It only can be load with "font=Somefont:style=SemiBold" or
"font=Somefont:weight=SemiBold".
On the other hand, it could be loaded when I tested the following commands.
fc-match -s ":family=Somefont:style=Medium" or
fc-match -s ":family=Somefont:weight=SemiBold"
Evas also should load font based on font's style name.
@fix
Test Plan: N/A
Reviewers: tasn, herdsman, cedric, woohyun, raster
Reviewed By: raster
Subscribers: Blackmole, z-wony, jpeg
Differential Revision: https://phab.enlightenment.org/D4108
evas-images2 example was broken due to excessive clipping.
This is one more issue with the cached clip geometry.
By default proxy_src_clip is true. The doc (that I wrote)
mentions that it means both objects (image proxy & source)
share the same clipper. So, this does not mean that the proxy
is clipped to the geometry of the source (this can be useful
in some cases, when replacing an object with a proxy to apply
some kind of effect on it... but this could be rare).
Thanks Amitesh for the report.
@fix
This fix is wrt the non-updation of the proxy object.
If a source of a proxy object has mapped objects among its children,
Rendering frame won't be correct while they were keeping changing.
The reason is, evas_object_smart_changed_get() couldn't figure those changes
out correctly because of cached-clip visibility.
Cached-clip of smart member can't be used for map surface updation,
because cached-clip includes the visiblity status out of the smart object.
So, loose the criteria to make it rendering smart members in map.
Summary: Which will apply translate property twice once to shape and once to origin.
Reviewers: cedric, jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4086
Summary:
Including camera and light to calculation aabb can lead to confusing in detemination
bounding of the whole scene (root node).
@fix
Reviewers: cedric, Hermet, raster
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4060
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The issue is that in some cases we were calling user code (callbacks)
when some of the nodes were referencing already deleted text nodes. This
caused invalid memory access. This commit delays the callback calling
until after all of the cursors got into a consistent legal state.
This goes back to a stupid comment I made in 93fad2a19f2507a:
No idea why evas_box was overwriting smart_data.get
(esp. since it was returning a private struct).
Well, it turns out the struct is NOT private and the smart
data pointer can be used by any user of evas box (including
Efl.Ui.Box).
Fixes T3926
This was discussed and still wasn't decided whether this is required to be
supported internally.
The reason for this revert is that the behavior still needs tweaking to work
just right along with the legacy behavior.
The cursor update hasn't considered when the pararaph is broken. The reason the
code path is different from legacy is because that it was originally intended to
support append and prepend operations in the new API. Since we don't anymore
(only supporting append operations in the new cursor with 'text_insert'), we can
simplify the insertion implementation and fix this.
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.
efl.gfx.fill will reset the filled flag, so the internal function
needs to be called instead of the gfx api.
This test error was added in a very recent commit: ccaf12e1b6.
This is a better fix than the previous patch, as it keeps
the legacy API check. The point of that check is: if the object
has been created with legacy API (evas_object_image_[filled_]add,
then legacy APIs are allowed, otherwise they are disallowed. This
means only EO APIs should be used on an eo_add() image object.
This is legacy stuff. I wish we could hide it from our inheritance
entirely. Instead, just make it abstract, remove all functions from
eo (doable here) and rename with the keyword "internal" in the new
ugly java style name.
smart_get and attach referred to an opaque struct, from EO
point of view.
Also, attach was an EO-only function, used nowhere besides
evas object smart itself, and evas grid (which is not EO
public API).
Note: Only two modes are supported (blend and copy).
The Efl.Gfx and Evas enums were different. All other values
were not supported. For legacy compatibility (since GL engine
actually implements some kind of support for all operations),
render_op_set() should still work fine, even though it's not
recommended, and won't work anymore with EO API.
This is a horrible API used for internal optimizations. Which
may or may not be partly broken anyway.
We can do better, in the future. Let's not expose this kind
of API.
The implementation depends on creating different code paths from the now-legacy
behavior of text appending.
The annotation system introduced in this commit replaces the current way of
applying formats on text.
Up until now it has been quite a hassle for the user to control the formats, as
it required keeping track of the format positions with an opener and closer
formats almost every time (with the exception of own-closing formats).
The combination of Efl.Text API along with the Efl.Canvas.Text annotation API
essentially replaces the capabilities of the old format.
There is additional annotation API to allow more control, so be sure to check
the documentation/.eo files and the wiki page of Efl.Canvas.Text.
The style API now accepts actual strings of format style. There is not longer
need to instantiate as style with style_new() followed later by style_free().
@feature
So, it seems my previous commit 79abba52c5 was a job
half done, as I forgot to remove Evas.Image from the inheritance
tree of all new evas image classes.
Somehow, there was code in the tree that apparently isn't tested at all, even
once - if it was, the eo.c logic that performs inheritance checks would be
triggered. I don't know how this could have happened (actually I do, it's
Cedric's fault and he should be publicly shamed for it) but these checks
make sure this will never happen again. But since the code itself appears
to be untested, I don't know if there isn't any other brokenness in it.
But that's beyond the scope of this change, so for now, let's make sure
all our inheritance is at least formally correct.
Also, enable eo_interface.eo generated code in Eo itself so that Eo.Interface
can be used when inheriting.
@fix
evas canvas will be removed from eo.
evas_output_XXX APIs are usually used by widget or e17.
I decided not open these kind of APIs to eo.
app can use the size of elm win instead of evas output apis.
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.
Jean-Philippe Andre
Youngbok Shin
Stefan Schmidt
Tom Hacohen
Carsten Haitzler
Boris Faure
Daniel Hirt
Daniel Hirt
Minwoo, Lee
Cedric BAIL
Daniel Juyung Seo
Marcel Hollerbach
Hermet Park
Subhransu Mohanty
Oleksandr Shcherbina
Daniel Kolesa
Ji-Youn Park
Benjamin Jacobs
Jean Guyomarc'h
JEONGHYUN YUN