Summary:
there was a case when a block could be realized while a item that is
realized was brought from one block to the this new one. The block now
is simply realized using api instead of just setting the flag, this sets
the correct focus registrations. While fixing this the error of double
regiration of items came up, this is also fixed by unregistration and
reregistration in the correct block.
fix T7247
Reviewers: zmike, SanghyeonLee, YOhoho
Reviewed By: zmike
Subscribers: Hermet, cedric, #committers
Tags: #efl
Maniphest Tasks: T7247
Differential Revision: https://phab.enlightenment.org/D6737
Summary:
this got replaced by the none composition implementation and is not
required anymore.
Depends on D6737
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6752
Summary:
the cache simply moved the objects to -9999 -9999 while leaving them
visible and focusable. Hiding them does not work since edje makes it
visible all the time again. Making them unfocusable fixes this.
Depends on D6752
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6753
itb-items is Eina_List, not Eina_Inlist. this crashes due to wrong type
use
ref D6720
fix T7246
Differential Revision: https://phab.enlightenment.org/D6736
Summary:
the focus model before was more meant for simplicity and not for
performance, this now is more made for performance.
The performance boost is achived by not using composition anymore,
but rather register realized items by hand. This keeps the amount
of items bound to the size of the viewport.
Additionally item realization that is followed by unrealization
immediately is not resulting in focus calls.
This solves the performance issue from T6580 in regards of focus.
perf results after this:
http://www.enlightenment.org/ss/e-5b61b50657f3c3.82619729.png
Reviewers: ManMower, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6720
I think at some point in the past this was necessary to avoid weird show
mechanics, but now things have changed and it's best to always attempt to
scroll and let the scroller internals figure things out
this resolves the case where attempting to scroll to an item during a genlist's
calc (ie. the item was not present in a full layout calc) would fail to scroll
to the item if the scroll method was TOP and the item was too close to the
bottom of the list
fix T6368
@fix
Differential Revision: https://phab.enlightenment.org/D6466
Summary:
We track list presence already, so we can just do a boolean test instead
of an O(n) lookup.
Depends on D6349
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6350
in the provider we accidently flattend out the widget history by
returning the wrong parent. However, this flattening code was required
for the element focus code of the two generic widgets, so the item is
found for every widget, in every subtree.
It is my understanding that some items view are created with efl_add directly
and manipulate VIEW directly with Eo new API. This clash with the inconsistent
behavior that evas_object_del expect. To work around this, we track object life
by explictely relying on efl_wref_add while holding the pointer to the object.
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
This reverts commit f0a0da9f44.
As per T5938 seems we really want to restore a totally wrong
behaviour, without taking care of newer apps being broken.
I revert this for now, but I'm still convinced that we must
find a way to let user use a sane ordering for newer app.
I'm thinking about adding an api in genlist to let the widget
use the new sane ordering, something like
elm_genlist_fixed_ordering_set(bool) so that new apps can use
this to ensure correct behaviour. zmike what do you think about
this solution?
Commit fd82c2521 has changed the behaviour of item_next/prev_get()
in case of genlist with group items (not tree).
The lagacy behaviour was to tread normal items and group items
in a flat way, like if group items was on the same level of
the children normal items.
As the commit already implement bug compatibility, seems to me
the case to restore also this case. Note that this changes only
apply to legacy genlist (I think).
Let me know if this broke something for you...as touching genlist
code is always an "I hope this is right" operation.
This patch implements bug compatibility.
genlist internally uses both a tree structure with Eina_List and a flat
Eina_Inlist to track its items. ALL of the items are in the inlist while
subitems appear in their parent's list. As a consequence both lists must
be kept in sync pretty tightly. Obviously this is not done at all and
has led to countless bugs, as soon as tree or groups are used:
- Invalid order of items (visually)
- Invalid order of items with sorted_insert
- Glitches in the matrix
- Crashes with sorted_insert
- Odd/even styles not properly set
- Promote/demote functions broken by design
- Developers send to psychiatric hospitals
- Etc...
Legacy genlist (1.19 and before) used an inlist order that basically
didn't make sense, as it didn't follow the logical order of elements (as
they appear visually). Unfortunately this has "worked" (really, that's a
huge stretch to use this word here) for a long time this way. As a
consequence, some applications (*cough* empc *cough*) have relied on
this order to implement "next album" or "previous album" where the
album title is a group node.
By changing the order of items in the inlist, this has broken the
assumptions made above, and ends up in cases that return NULL, leading
to SEGV. Sure, the app should have checked NULL, but that's not really
the point here. The behavior has been changed.
This patch implements "fixes" for the following functions:
- elm_genlist_first_item_get(): Don't return a parent
- elm_genlist_last_item_get(): Return a parent
- elm_genlist_item_next_get(): return a parent upon reaching the last child
- elm_genlist_item_prev_get(): return a child when a parent is passed
Important notes:
- This does not cover 100% behavior compatibility here. The only way to
have it would be to simply revert the entire genlist code to its
original version and never touch it again, ever.
- An explicit API is required for an application to specify which API
level it targets, so that we can cherry-pick which bug compatibility
features we want to enable. We are already doing this for EDC,
unfortunately.
@fix
fix T5938
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
better rely on the adapter and wait for realization so the adapter is
wether created or not even created but used with content. This fixes
item content focus, crashes at startup and a freeze in genlist test!
elementary_test -to genlist
-> LOTS of warnings, when creating the genlist, as the items aren't
ready yet. This just avoids the WRN as recalc will happen later anyway.
Following @taxi2se's recommendation. This is indeed a focus method, and
Widget already inherits from Focus.Object.
Ping @bu5hm4n who probably wants to adapt this further.
Ref T5363
Summary:
Send signal EFL_ACCESS_STATE_ANIMATED when dragging starts and stops to atspi clients and also set EFL_ACCESS_STATE_ANIMATED
when reorder mode is enabled.
Test Plan: When reorder happens atspi client should receive object:state-changed:animated signal.
Reviewers: kimcinoo, shilpasingh
Reviewed By: shilpasingh
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5515
Marcel Hollerbach
Mike Blumenkrantz
Derek Foreman
Cedric BAIL
Marcel Hollerbach
Davide Andreoli
Xavi Artigas
Daniel Kolesa
Jean-Philippe Andre
Mike Blumenkrantz
Amitesh Singh
Prasoon Singh
