Summary: Changes in the _item_realize to decorate the item T576 test_genlist10
Reviewers: seoz, singh.amitesh
Differential Revision: https://phab.enlightenment.org/D358
If we're walking an item and it's deleted, the memory won't go away
immediately in _item_del_pre_hook() as would in _item_del(), then it's
not enough to remove ourselves from the reverse-relative list of the
item we were relative to, we also need to clean our own relative
pointer so we won't touch it later when the item is not being walked
anymore and _item_del() is called.
I was getting this annoying error with espionage application, opening
an interface of an object and then closing the window or selecting
another bus name (whatever would call elm_genlist_clear()).
During the clear process genlist will flag the next item as "walking"
so it's not gone when the current item dies (would happen if next item
is a subitem). The item would run _item_del_pre_hook() but not
_item_del(), but on the next loop iteration the next item would be the
current, then not walking anymore and during _item_del() it would
access it->item->rel which would point to the now-dead item.
When we scroll the genlist with decorate all mode, newerly realized items looked like a normal mode.
This was caused by a new theme. Genlist item style should handle all the necessary parts when decorate mode is enabled/diabled.
This fixes T576.
Now it looks like a normal efl app.
- Declare variables at the start of the function.
- Resize and show the window right after its creation.
- Set widgets' parents properly.
This fixes " _smart_need_recalculate_set() Object 0x803db8e8 is not stable during recalc loop" issue which was reported by kuuko.
Special thanks to kuuko.
before this, it had the insane logic so the prescale_set() never work.
Now, it works well and the prescale won't be set in default. (before, the default value is 64. why?)
When the content is removed(or unset) the mapbuf didn't clean up the some stuff such as removing event callback for the content.
So the unset content would be tracked still by mapbuf dangling callbacks.
Thank you eo pointer indirection for detecting this.
The issue is a mix of design choices (will discuss on the ML) and
a bug in hoversel which was probably caused because of the confusing design
choices.
The problem is that while widget_item->view is set by whoever created
the item, it's automatically deleted by elm_widget_item_del. This means
that objects that decided to delete their views, but were too sloppy to
update the widget_item->view pointer to NULL, would trigger an attempt
to deleted an already deleted object. This does not happen in 1.7
because widget_item->view was introduced in 1.8.
The automatic view deletion is problematic, as smart subobjects are
already deleted when the parent subobject (the widget) is deleted. So
clearing the views is redundant. However if the widget item is manually
deleted, the view should be deleted. This causes this mixture of cases
that are problematic at best.
Indication error:
Error:
ERR<5394>:eo lib/eo/eo_ptr_indirection.x:275 eo_obj_pointer_get()
obj_id 0x8000002900000149 is not pointing to a valid object. Maybe
it has already been freed.
This fixes T500.
Carsten Haitzler
nirajkr
Gustavo Sverzut Barbieri
Tom Hacohen
Daniel Zaoui
Daniel Juyung Seo
Seong-ho Cho
Rafael Antognolli
Daniel Juyung Seo
ChunEon Park
maxerba
Jihoon Kim
Sanjeev BA
WooHyun Jung
Ryuan Choi