Summary:
When multi down or multi move occur, state of touch point changes to EVAS_TOUCH_POINT_STILL.
So I add condition, "state == EVAS_TOUCH_POINT_STILL"
Reviewers: jypark, woohyun, cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5157
Summary:
If the object is outside the parent geometry because of map,
this object would be ignored in determining object is in the event area.
Please refer to below case
1) There are some button in the box object
2) A button has map with 90 degree.
It would be placed outside the box geometry
3) If you press the button part outside the box,
the button event does not work.
Test Plan: sample code
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5180
This fixes scrolling in rage.
Lessons learnt:
- Do not trust raster's bisecting skills ^^,
- Do not blame GCC until you're 100% positive about the exact code
triggering an issue,
- va_arg is unsafe, and can lead to crazy issues like this one,
- va_arg passes (int x, int y) differently from Eina_Size2D sz, and
optimization flags may also affect how that's done, or at least what
kind of garbage data is used.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
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
this has affected edje for... like... ever. min size of boxes just
doesnt work. because evas box just doesnt do it right. this has led to
nasty things where edje box is just not usable if you use weight of 0.
btw weight 0 means "stay at min size no matter what even if we expand
the box to be bigger" in edje... which is totally broken and i can't
fix that without potentially breaking even more stuff... but let's
see. i've been using this for several days now and ... i can't find
breakage... so this should fix up SOME issues in edje.
@fix
This API was introduced in commit:
cd3f8db506
This was since limited to EO only APIs, and totally underexploited.
After that, efl_part() was introduced, which defines how all part APIs
should be designed.
Nothing uses this API, efl_vg had an implementation that provides no
extra value over the other APIs.
This changes the CRI logs and the variable names.
I still think this API needs some fixing in order to not abuse the
smart object API. This should be done before it's too late (i.e. E is
released and depends on it).
This is a new function that indicates whether an object is a child of a
parent or not. Dead simple, as this simply compares if parent == this.
Note that this check was impossible to do with the event grabber.
Also, rename group_children_iterate to group_members_iterate for
consistency with the other group_member functions.
@feature
Inside emotion, if Eio is compiled, some asynchronous functions are used
and a refcounted struct was used to ensure safety of the code.
Unfortunately the logic didn't make much sense as emotion's private data
is used. The refcount becomes useless, the lifecycle of the data being
bound to the object itself.
Note that an actual crash is almost impossible because:
- eio is actually quite fast
- evas objects are kept alive for 2 frames
- eina_freeq is used to keep eo objects' data alive for some more time
But this in theory fixes the events, as they were sent on the wrong
object. "obj" is the image object, "smartobj" was the emotion object.
This is fixed with a weak ref.
I don't think it is necessary to backport this.
It's not exposing anything that wasn't already accessible before (you
could just add a member and get its clip, for instance).
This will be used by Edje Object.
This is a minor
@feature
- color_set
- visible_set
- position_set
- no_render_set
- member_add, member_del
- group_add, group_del
- clip_set
Notes:
- Widget overrides color_set without calling super() which means that
color_get() returns a different value. Also any subsequent child
object add will not inherit the color.
- Smart clipped objects also don't call super.
This patch changes that, but only for smart clipped objects created
through EO. This shouldn't have any side effect.
Introduction to the problem:
- Efl.Canvas.Group has a method member_add() to add sub objects.
- Efl.Canvas.Group (simple smart object) does NOT actually delete the
objects on deletion. But:
- Efl.Canvas.Group.Clipped is a direct subclass and WILL delete the sub
objects on deletion.
Semantically, all smart objects (at least in EO and Elementary) will own
and delete sub objects automatically. Some exceptions are:
- Edje object (smart clipped) does not delete swallowed objects.
Edje object is a "clipped" smart object but it pops out all swallowed
children before getting deleted.
- Evas box/table/grid also pop out their children before deletion.
Those classes are all legacy & internal only.
- Elm.Widget will "manually" delete all its sub objects at deletion, as
it inherits from Efl.Canvas.Group but basically takes full ownership
of the sub objects. Note that member_add shouldn't be used on a
widget, the widgets do it themselves.
Also, smart clipped objects are much more convenient to use as they will
handle some things for you: color, visibility, moving and ownership.
So, the API member_add needs to be marked as own(). But right now
Efl.Canvas.Group does not own. Thus, here's the plan:
- Mark clipped objects as such with an internal API
- Merge clipped smart object features directly inside the standard
smart object.
- Get rid of Efl.Canvas.Group.Clipped entirely and watch all hell break
loose.
Ref T5301
Summary:
INHERITED script unicodes are only meaningful when it comes
after the previous unicode from same font.
Even if there is no glyph for the INHERTED script unicode from current font,
don't search other font for loading the unicdoe as first unicode
of next item. It will be meaningless.
@fix
Test Plan:
Check the following Emoji sequence with an emoji font
which does not have variation selector glyphs.
{ 0x1F3F3, 0xFE0F, 0x200D, 0x1F308 }
Reviewers: raster, cedric, herdsman, jpeg, woohyun
Reviewed By: herdsman
Differential Revision: https://phab.enlightenment.org/D5156
Summary:
Becuse ox is set to 0,
it cannot be negative, so negative check will be needless.
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5155
This is an attempt at fixing crashes in empc.
Test scenario:
ELM_ACCEL="" elementary_test -to "Gfx Filters"
And mouse scroll like crazy in the spinner.
@fix
Summary:
When harfbuzz is enabled, _content_create_ot() function will be used
for shaping. If evas_common_font_int_cache_glyph_get() failed in some reason,
it never proceed gl_itr until the end.
It can cause weird rendering result. Because, all of gl_itr after the failure
can't have proper x_bear, y_bear and width.
@fix
Test Plan: N/A
Reviewers: raster, cedric, herdsman, jpeg
Differential Revision: https://phab.enlightenment.org/D5154
a canvas can have multiple objects with the same name. assuming that name:obj
is a 1:1 ratio means that name-finding functions are likely to return invalid
objects
@fix
Summary:
Assigning a result of integral division to a double type variable is
not useful for next division calculation. For more accurate calculation,
it needs to be casted to double before doing division.
It does not fix some bugs. It was reported by a code quality advisor.
Test Plan: N/A
Reviewers: raster, cedric, jpeg, herdsman, eunue
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D5069
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
This is a very informative document but is much longer than it needs to
be. Tighten it up by condensing redundant information and expressing
the ideas more efficiently. Focus more on Evas and what it is than what
it isn't. Avoid explaining general graphics concepts like immediate
vs. retained, replacing with synopses. Switch from 2nd person to 3rd
person (i.e. don't say You/Your) to be less awkward, since we don't
really know why the reader is reading it. Simplify the compilation
directions; these are pretty standard, and most people won't be manually
linking to Evas anyway.
While this shortens the document considerably, it retains the
important key points, and makes it far more readable.
Reviewers: cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5130
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
evas_textgrid_cellrow_get() is supposed to return NULL if the row index
fed to the function is outside of the textgrid's range. It was instead
returning garbage pointer.
@fix
This fixes a case where an object is hidden before the first render.
When called from elementary. the visible intercept code would be called
before evas object's visible_set, bypassing the line setting visible_set
to true.
As a consequence the object would be visible even when explicitly
requested as hidden.
Thanks @JackDanielZ for the report!
For now, do not use Evas_Canvas3D in multi output context, it won't work.
The update code for Evas_Canvas3D_Node might trigger rendering logic, which
is opposite to what the scene graph logic should do. It require to much
reshuffle around to handle that case at the moment. So I am just adding a
warning.