Scrollto positions are divided 4 type
NONE : do not scrollto.
TOP : scrollto position is always top viewport.
MIDDLE : scrollto position is always middle of viewport.
IN : scrollto position to fully visible in viewport.
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.
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.
Summary:
Menu items in dbus-mode (in Ubunut/Unity) were not updated on
disabled/enabled state changes. They were applied only after
adding/removing an item.
Reviewers: cedric, seoz, raster
Reviewed By: raster
CC: reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D333
- removed unnecessary duplicated parameter passing.
- moved smart callback add to a proper place not to be confused with other object's smart callback addition.
- removed unnecessary sub object add. it's done automatically in elm_layout_content_set.
inline with their X counterparts. Also, remove some EINA_UNUSED where
parameters were being used.
The previous code to get the Ecore_Wl_Window from an Ecore_Evas did
not check to make sure the Ecore_Evas Engine was a wayland engine, and
thus elm_tests like Window Inline would spew CRIT & ERR messages from
ecore_evas about the interface.
This fixes Phab Ticket T502
Signed-off-by: Chris Michael <cp.michael@samsung.com>