since this can take an extension as well as a file path (extension
being .gif or .jpeg etc.) it would skip if passed a small extension
only (5 chars or less). fix and this fixes e's thumbnailing too for
some files.
@fix
Summary:
The fribidi couldn't reorganize paired brackets (Ex. '(', ')')
when there is RTL + LTR text. According to TR9(http://www.unicode.org/reports/tr9/),
it has to be shown properly without LRM or RLM.
Also, from the fribidi 1.0.0, fribidi_get_par_embedding_levels() was deprecated.
It is replaced with fribidi_get_par_embedding_levels_ex() which is including
paired brankets rules from TR9.
@feature
Test Plan:
1. Create a elm_entry.
2. Set a text by calling text_set.
elm_entry_entry_set(entry, "مرحبا Hello (40)");
3. Run and see the results.
- Without this patch or fribidi 1.X.X, it will show text like this...
"(Hello (40 مرحبا"
- With this patch and fribidi >= 1.0.0
"Hello (40) مرحبا"
Reviewers: raster, cedric, herdsman, woohyun
Reviewed By: herdsman
Differential Revision: https://phab.enlightenment.org/D5921
Change the parameter name of property event_animation from "event_type"
to "desc" to synchronize with other APIs.
(The parameter type is Efl.Event.Description)
Previously, beginning state of animation is applied after animation is
finished if final_state_keep_get() is false.
Now, map is reset (no animation is applied) after animation is finished
if final_state_keep_get() is false.
To synchronize other types of event info,
Efl_Canvas_Animation_Player_Running_Event_Info is changed to
Efl_Canvas_Animation_Player_Event_Running.
Remove unused struct.
Old version algorithm was imperfection a bit, quality was poor at some specific
degrees, specifically, when pixel increment pattern on the diagonal lines is
unstable.
This revised version was better than old one even source code is much cleaner
and simpler.
See belows.
*NonAA vs AA:
https://ibb.co/bCNfMc
*Compare the worst case aa in the old version:
https://ibb.co/bEJsZx
*Test video:
https://youtu.be/Wn20Tym5lfg
Summary:
this commit add null check.
In EVAS_OBJECT_DATA_SAFE_GET, if eo_obj is null, obj can also be null.
and In _efl_canvas_output_async_block() can return null.
Test Plan: N/A
Reviewers: woohyun, kimcinoo, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5870
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
[Dereference after null check]
(1) src/lib/ecore/ecore_main.c
- _efl_loop_handler_efl_object_finalize checks if pd->loop_data is NULL.
After that, _handler_reset > _handler_clear > _ecore_main_fd_handler_del >
_ecore_main_fdh_pool_del is directly dereferencing pd->pool_data.
- _efl_loop_handler_efl_object_parent_set checks if pd->loop_data as well.
Then it calls _handler_reset as well.
(2) src/lib/ecore_wayland/ecore_wl_dnd.c
- ecore_wl_dnd_selection_set checks if t - result of wl_array_add - is NULL.
And it is dereferecing t directly for wl_data_source_offer.
(3) src/lib/elementary/efl_ui_dnd.c
- Third parameter const char *data could be NULL.
In this case strlen dereferences NULL. The data should be non NULL value.
I have checked this with Mr. Thiep Ha.
(4) src/lib/evas/canvas/evas_object_inform.c
- _efl_canvas_object_efl_gfx_stack_stack_below checks if obj->layer is NULL.
So it could call evas_object_inform_call_call_restack which is dereferencing
obj->layer directly.
Evas map supports anti-alias(aa) rendering on sw backened.
When aa is toggled on, map forcely turns alpha channel on while it draws on the surface.
Actually, it was intended to blend polygon edges with destination,
but it breaks one case if the original source image alpha channel were turned off.
Simply, it fixed the issue, new implmentation removes the alpha channel switching,
instead fill the alpha values with 255 when map + aa + alpha_off is drawing on it.
@fix T1975
Evas map anti-aliasing haven't worked at all if the smooth scaling were disabled.
evas map rendering has a lot of corner-cases, previous call-position was wrong,
(by mistake maybe) shouldn't be in a certian case.
Let aa post-processing function be performed in universally.
Ector renderer are created by a factory pattern which return a reference.
The possible logic improvement from here would be to rely on setting the
parent of the object to the Ector_Surface and manage a cache by intercepting
efl_noref to trigger an efl_del of the object or a temporary cache of it.
That's for later.
Summary:
this commit add null check logic on evas_object_smart_attach
because a segmentation fault occurs once the argument is not valid (eg. null).
Test Plan:
1. invoke evas_object_smart_add(obj, NULL)
2. see the application crashes
Reviewers: woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D5817
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
ok. i can't find the root cause because all i have is a backtrace from
ApBBB and he says he can't reproduce it and i know im->cache is
null... if i could reproduce ... i'd be hunting the root cause. but
the best i can do is check for null im->cvache ptrs and be safe.
crashes are bad. especially for end users.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
also implement Efl_Canvas.objects_at_xy_get
note that any function which returns an iterator cannot be @const since
it's necessary to wref the object to ensure the iterator's lifetime
this file contains canvas methods which should be subject to compiler
type checking, requiring that they be included in the file which contains
the eolian generated code
this reveals existing breakage which went unnoticed due to the compiler
being unable to do type checks since the generated eolian code was not included
Summary: As the gfx_path mixin class destructor is not called hence explicit call of reset.
Reviewers: jpeg, SanghyeonLee
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5803
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
every canvas object has had this leak for some time:
==25217== 64 bytes in 1 blocks are definitely lost in loss record 1,669 of 3,515
==25217== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==25217== by 0x688D839: eina_hash_new (eina_hash.c:755)
==25217== by 0x688D940: eina_hash_string_superfast_new (eina_hash.c:791)
==25217== by 0x6265F8C: _efl_gesture_manager_efl_object_constructor (efl_gesture_manager.c:66)
Summary:
Calling evas_object_polygon_add(NULL) cause segmentation fault,
because there has been removed null check logic in evas_object_polygon_add(0ff7429)
This patch fix the problem.
Test Plan:
1. Call evas_object_polygon_add(NULL)
2. Check segmentation fault happen
Reviewers: cedric, jpeg, woohyun, jypark
Differential Revision: https://phab.enlightenment.org/D5801
This change finally introduces deferred parsing of inherits to
Eolian, after a long time and many iterations. That means instead
of parsing inherits directly as part of the main file's parse pass,
they're pushed into a queue and parsed later. The validation engine
was modified to properly fill in the remaining info afterwards.
This may introduce breakages but I haven't noticed any. It also
properly unlocks cyclic dependency support in Eolian.
Additionally, this also introduces checks for duplicates in class
inherits (class Foo(Bar, Bar) is no longer possible) and it adds
stricter name checks, so you can no longer have a class Foo.Bar
and refer to it as Foo_Bar in implements. This was actually never
meant to be supported, but the check was previously broken.
@feature
This interface has a simple 'create' method to create Efl.Canvas.Object
given a key.
This is used higher-up in Ui.Text in the next commit.
Ui text: add ability to set item factories
Added API to set an item factory object.
This is similar to the previous item providers (that worked with
callbacks).
You instantiate a factory object and set it on the Ui.Text object.
Each factory implements the "create" method from
Efl.Canvas.Text.Item_Factory.
This also includes 3 public factories (Image, Emoticon and Fallback):
- Image factory: creates images from added entries (key strings)
- Emoticon factory: creates emoticons by querying the theme
- Fallback: creates image, then falls back to emoticon
If no factory is set, then the fallback (internal) factory is used.
See the added "Ui.text Item Factory" test in elementary_test for an
example of usage.
@feature
No need to split: those two are used in all the same classes, since the
split between Orientation and Ui.Dir.
Note that the enum types remain in the main namespace.
For SW engine we need to verify that OSMesa is present. The patch
fb048e7312 broke the logic.
Tested by temporarily removing OSMesa from my system.
Fixes T6617 (again)
Summary:
Efl.Player interface simply provides play functions,
but another interface which indicates Efl.Player will play is also
needed.
Test Plan: Run elementary_test->Efl.Animation tests
Reviewers: woohyun, conr2d, Jaehyun_Cho, jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5662
we can't sensibly use things like massif to track memory if we bypass
itr with mmaping -1 fd anonymous memory... so if built with valgrind
support and running under valgrind, use malloc/calloc and free so
these tools actually do something useful for these bits of memory.
Fixes a bug introduce with c8c4572d70.
My guess is that the true intention was to query the Efl.File mixin
first, and the check the specific load_error.
Basically a call to 'efl_file_load_error_get' on an
Efl.Canvas.Image triggered this.
Public symbols were defined internal to Evas/Elementary on macOS, making
the link of external modules unfeasible.
- EAPI was messed up by an invalid inclusion of evas_text_utils.h, making
some symbols private instead of public.
- A similar issue was present in evas_font_draw.c, where the symbols
were directly imported without the proper definition of EAPI.
- Elementary.h did include some eo-generated headers, but for windows
only. It should not been restricted to windows, as it allows to export
symbols to external modules.
Fixes T6448.