This allows doing ugly things such as setting a clipper/mask
on any smart object, without having to worry about seeing a
white rectangle cover the whole screen.
While the above scenario is not a great idea (bypass elementary in
its handling of the clipper), having a big white rect covering the
entire UI seems even worse.
I wonder if elm objects shouldn't simply allow user clippers, and
somehow manage them along with the smart object internal clipper.
Setting the no-render flag on an elm widget had no effect,
as it was not properly propagated to its children. This should
fix that, but I'm not a fan of the solution.
Fixes T3371
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
height of the children b-box should be arranged by parent y-pos.
Signed-Off-By: KeuckDo Bang <keuckdo.bang@samsung.com>
Signed-Off-By: MinKyu Kim <imetjade.kim@samsung.com>
@fix
Summary:
It adds evas_object_paragraph_direction_set, get APIs.
The APIs set or get paragraph direction to/from the given object.
It changes BiDi calculations and affect the direction and aligning of text.
It doesn't have any effect to text without Fribidi library.
The default paragraph direction is EVAS_BIDI_DIRECTION_INHERIT.
If dir is EVAS_BIDI_DIRECTION_INHERIT, paragraph direction is changed
according to smart parent object. If there is no smart parent object,
paragraph direction works as EVAS_BIDI_DIRECTION_NEUTRAL.
@feature
Test Plan:
Test cases included to the following files.
- evas_test_textblock.c
- evas_test_text.c
- evas_test_object_smart.c
Run "make check".
Reviewers: woohyun, raster, herdsman, tasn
Subscribers: c, raster, cedric
Differential Revision: https://phab.enlightenment.org/D1690
While cached surfaces is a topic we're discussing recently,
this code is dead right now, and we will have to redesign the
buffer caching better to handle proxies, maps, smart objects, etc...
Summary:
Evas_Smart_Data retrieved from eo_data_scope_get might be NULL
in case the input Evas_Object is not valid Evas_Object.
The smart data gets dereferenced and can cause a crash if its NULL
Hence return in case smart data is NULL.
@fix
Signed-off-by: Mrunal Sovani <mrunal.s@samsung.com>
Reviewers: raster, Hermet, tasn
Reviewed By: tasn
Subscribers: singh.amitesh, cedric, sachin.dev
Differential Revision: https://phab.enlightenment.org/D3106
Otherwise there would be conflicts in certain circumstances.
This also requires adding const on many existing functions,
and similar work is necessary in Elementary.
@fix
Summary:
Size may be zero while allocating interfaces private data,
when NULL is passed in EVAS_SMART_SUBCLASS_IFACE_NEW for ifaces argument.
If size is 0, then malloc() returns either NULL, or a unique pointer
value that can later be successfully passed to free(). It is implementation
dependent. This case would be likely to occur in case of smart classes with
no interfaces.
@fix
Signed-off-by: Vaibhav Gupta <g.vaibhav1@samsung.com>
Reviewers: raster, Hermet, tasn, cedric
Subscribers: SanghyeonLee, sachin.dev, singh.amitesh, cedric
Differential Revision: https://phab.enlightenment.org/D2679
Summary:
As we always call evas_object_inject in every Evas Object's ctcor,
it seems sensible to move this repeated bit of code to the super
(Evas.Object).
Test Plan: Expedite, Elementary_Test and pretty much everything
Reviewers: cedric, raster
Subscribers: JackDanielZ, cedric
Differential Revision: https://phab.enlightenment.org/D2665
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
this adds a lock for when walking all the objects to generate render
commands for an async render. this allows even the object tree walk
plus update area caluclation to be moved off into async if every oject
that can change canvas state actually does so correctly. this change
adds all those lock block calls to synchronise with an async object
tree walk.
Before this change eo_add() used to create an object with 1 ref, and if
the object had a parent, a second ref.
Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
preserves the old behaviour (for bindings).
eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
eo_unref (will change to be a way to ensure an object is dead and goes
to zombie-land even if still refed).
Summary: Fix not to clean and re-render if the position of an object enabled map is changed.
Reviewers: raster, cedric, Hermet
Reviewed By: Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1220
const have been added in object parameter of two legacy APIs to fit
Eolian generated files.
Since these functions retrieve information from object, it is logic that
the object would be const.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
This reverts commit 1319733cae.
Let's revert this patch and lower the recursion number.
As we released efl 1.8, let's find the root causes of the problem and fix them.
I already told this revert to raster so I am not mean :)
By tranversing the whole of the map target's tree,
it decides to update the map surface to be redrawn if one of the objects is changed except the clipper itself.
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c