==1321== 156 bytes in 1 blocks are definitely lost in loss record 7,687 of 9,703
==1321== at 0x4847E64: calloc (vg_replace_malloc.c:623)
==1321== by 0x92EA7E9: wayland_im_context_new (wayland_imcontext.c:1094)
==1321== by 0x92E66DD: im_module_create (wayland_module.c:132)
==1321== by 0x4D521E7: ecore_imf_module_context_create (ecore_imf_module.c:152)
==1321== by 0x4D51EF7: ecore_imf_context_add (ecore_imf_context.c:141)
Summary:
If orientation is TOP, BOTTOM, LEFT and RIGHT and
tooltip was moved due to located out of screen,
adjust location of arrow so that can indicate right position.
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Test Plan: elementary_test -to tooltip4
Reviewers: cedric, Hermet, jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4554
Summary: I had fixed some typos and wrong expressions, euch as capital letters, singular Etc. in Ecore and Edje API reference doxygen.
Test Plan: Doxygen Revision
Reviewers: stefan, cedric, raster, Jaehyun_Cho, jpeg
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4677
Covers: Ecore_Drm, Ecore_Evas, Ecore_File, Ecore_IMF, and
Ecore_IMF_Evas API reference doxygen.
Summary: I had fixed some typos and wrong expressions, such
as capital letters, singular Etc. in Ecore_Drm, Ecore_Evas,
Ecore_File, Ecore_IMF, and Ecore_IMF_Evas API reference doxygen.
Test Plan: Doxygen Revision
Reviewers: stefan, cedric, raster, jpeg, Jaehyun_Cho
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4680
The key was to emit & process the signal to the edje objects
(item views) at the same time as we move them, ie. from the
loop in _item_block_position().
Also the proper counting must be used at all times. Hidden
items should not be counted.
Tree effect may still have issues but otherwise there is no
more blinking, double odd or even rows, etc... It all looks
good (as long as there is no tree effect!).
Fixes T3086
@fix
When using the fileselector in tree view mode (ie. expandable),
expanding any folder with a lot of files in it would cause the
genlist view to jump somewhere to the bottom. This is because
the mechanism preventing the view from moving was assuming that
all "prepend" operations meant prepending before the selected
item. This is not the case in case of expansion like in the
fileselector.
@fix
If an item is selected, and another item is insert before
the selected item, then we try to lock the genlist view (pan)
around the selected item (if it's visible). Unfortunately,
every 16 inserts cause a jump by one line in the scroller.
That's because the scroll math assumes the block position is
known, but since it's a new block it wasn't known.
This patch fixes this issue by precalculating the block position.
Test scenario:
elementary_test -to "Genlist Tree, Insert Relative"
Select an item, clikck 50 times on "+ before".
The view should not jump.
This does not fix fileselector's craziness.
@fix
This fixes the internal item order index.
Note that groups don't reset the odd/even styles. The
original code wasn't very clear on the intent (setting
to 0 in one case, not increasing the counter in another,
but that was not consistent all over the place). I believe
resetting the odd/even styles at a group boundary would
look great, but this might be for another patch :)
This amends part of another commit, but keeps its feature:
b40a6eb85bf44a genlist: implement list position signals.
See T3086
PS: I've discovered more odd/even issues with the
fileselector in particular. Still working on it...
@fix
This reverts commit 43d82e567a.
I don't understand this commit. It broke the logical order of
items, as the internal list wouldn't match the order on screen.
Other places in the code didn't seem to make this assumption
that parents come after their children. And for sure my recent
fixes require the parent to come before.
This commit was one of the many reasons why odd/even styles
look often wrong.
See T3086
It was used to hide "it->item"... but was used less than it->item
itself. Explicit code here is not longer, and just as readable.
This macro I think was harmful to readability.
Simple sed, no real change at all.
Not sure how long this has been broken, but the variable name changed
in this routine to "is_gl_accel"..."is_hw_accel" is no longer used, so
change variable name here to fix compilation with SDL.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
elm_pan_gravity_{set,get} are functions that were generated as
legacy APIs (in other words EAPI), but were never actually exposed
to applications as they were protected behind EFL_EO_API_SUPPORT
(see elm_interfaces.h).
This patch restores the ABI compatibility with elementary 1.18.
This fixes a lot of cases where a genlist node (of any type)
with children may have appeared in the invalid expanded or
contracted state.
Before this patch, the test case "Genlist tree, Relative insert"
looked like below (all items are programmatically added):
> A
> 1
> 2
> B
> 3
> 4
The problem above is that A and B have visible children but
still believe they are in contracted state. This patch ensures
that A and B will be marked as expanded, but will do so without
firing an "expanded" signal and definitely without the
"expand,request" signal.
After this patch, the test case will look like this:
v A
> 1
> 2
v B
> 3
> 4
Which is more correct. Note that this test case does not handle
any expand/contract signal.
NOTE: This is a behaviour break!
This fixes a case where inserting item "C" after item "B" in this
tree would go wrong:
A
B
- 1
- 2
Before this patch, 1 and 2 lose their parent:
A
B
C
- 1
- 2
After this patch, 1 and 2 retain their parent:
A
B
- 1
- 2
C
Insert before worked by luck, no need to fix it.
Note that this patch may require the next one to actually
work (ensuring expanded state flag).
NOTE: This is a behaviour break!
This fixes the test case "Genlist Tree, Insert Sorted".
This is a pretty ugly patch... but the genlist code is already
pretty ugly, as it keeps a flat inlist of items (sd->items)
as well as a tree structure in parallel.
Before this patch, the following configuration led to issues:
1
3
- A
- B
Adding item "2" led to a crash. Adding item 4 led to this:
1
3
4
- A
- B
Items A and B lost their parent "3". Subsequent sorted inserts
would lead to insane bahaviour, where for instance "8" would
appear before "3".
This patch fixes all sorted inserts, at the cost of performance
(an optimized code path is avoided). Subsequent patches will
increase the robustness of the tree structure.
NOTE: This is a behaviour break!
Fixes T4850
Summary:
Change the item indexing to start 1 after reordering animation.
Change the logic of edge checking to get the row or col correctly.
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Test Plan:
elementary_test -to gengrid2
append 6 items
enable the reorder mode
check reordering is working properly (4 to 1)
@fix
Reviewers: singh.amitesh, cedric
Subscribers: jehun.lim, jpeg
Differential Revision: https://phab.enlightenment.org/D4676
With the new Efl.Ui.Clock widget, which implements Datetime,
most parts are relative to each other, and trigger a near-inifinite
recalc of all the parts. Indeed edje was recalculating a part even
if it had already calculated it (flag is set).
This seemingly simple patch fixes Datetime and probably a lot
of other edje widgets.
Fixes T4909
@fix
Some property set calls to Evas Text are NOPs if the property was
already set to the same value. Avoid doing any work then.
This adds a missing intercept call (size_set as it's overriden
by Evas.Text).
I was in a situation where my elm_config had the proper version
but did not contain a proper module name for the clock widget.
This resulted in not being able to create any field object in
the clock widget... in other words it made for a very useless
clock :)
Ideally the config should be updated at this point. I'm not
sure how to proceed exactly, though :(
Jihoon Kim
Minkyu Kang
Myoungwoon Roy, Kim
Jean-Philippe Andre
Carsten Haitzler
Mike Blumenkrantz
Daniel Kolesa
Chris Michael
Felipe Magno de Almeida
Lauro Moura
Andrii Kroitor
Amitesh Singh