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
Conditions:
- style is "double_label"
- the is some content for items (i.e elm_label)
- elm_genlist_filter set was once called after genlist creation with
NULL data
- label_get callback uses elm_genlist_item_prev_get on its current item
- at least one item is added as a sub-item
- ~2 blocks of items are added afterwards
- items are added quickly while holding 'enter' on an elm_button
@fix
This thing is used by only 2 EO APIs that are marked as @beta. I wonder
if the @beta tag or the ptr() expression made it work for eolian,
because it simply wasn't defined in EO.
I'm renaming it just so that it's more consistent with the new names
used by atspi (and EO API in general).
When using reusable content, genlist preserves old object's state and is
expecting reusable_content_get callback to change all needed properties.
But there was an inconsistency: it was silently re-enabling the old content.
@fix
This will be used to solve issues around style_set:
if the widget is legacy or pure eo we may need to select a different
style. So in the constructor we need to know whether we are legacy or
eo. Note that calling style_set in finalize only is too late as we would
lose information such as efl_text_set() called inside efl_add().
This prevents legacy EO classes from being exposed through .eo.h headers
or .eo in share/eolian/includes. Also removes a slew of useless xxx_eo.h
intermediate headers.
Notes:
- elm_systray has no proper API: it's not clear if the EO API should be
released (in which case it needs to be renamed to efl_something) and
there is no legacy API to create a systray object.
- Some files have been placed in a "FIXME" section, as I believe they
are necessary within EO land, but at the same time still don't
conform to the interfaces (eg. name starts with elm_).
- elm_interface_scrollable is required by photocam. This means photocam
needs to be adapted to fit the EO scroller API (still to be
completed, I believe).
Bugs:
- This breaks most C++ examples. I KNOW. And I'm working on it.
Ref T5301
Summary:
**@feature** T6241
This feature enables genlist to pin an item to viewport which will
be available always for user to view/select.
**Use Case**:
In a big list of music, most times when user finds a song which they
like, before playing that they may want to go through the entire list
to check whether there is some other good songs, but
after seeing the entire list user have to again scroll back to the
position of item which they liked to play it then.
In this case item pinning can be used, so that the item
which they want to keep for future selection can be pinned
and then it will remain in viewport, finally when user want to do
operation on item, it will be readily available in viewport.
Signed-off-by: Godly T.Alias <godlytalias@yahoo.co.in>
Test Plan: Elementary Test -> Genlist -> Double click on items to enable/disable pinning
Reviewers: raster, cedric, prince.dubey, SanghyeonLee
Subscribers: rajeshps, jpeg, shilpasingh
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D5340
Item prev/next/first/last.
If true, break, else, break.
EO_OBJ(x) is safe on NULL.
Add a simple macro to simplify inlist handling.
Overall simplify the code.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
fix decorate mode crash issue reported by Jack Daniel in T6000
which is occured by dangling pointer in item deletion on decorate mode.
Signed-off-by: SangHyeon Jade Lee <dltkdgus1764@gmail.com>
It's not beta. It's about to die.
Also, move #define ELM_WIDGET_BETA to the common header file, as it is
consequently required by ALL widgets. :(
Ping @bu5hm4n :)
Ref T5363
I was told that the scrollable interface is being redesigned for EO.
This API definitely does not belong to the base Widget class, as it's
quite specific to item-based scrollable widgets, such as lists and
grids. Since Elm.Interface_Scrollable is itself being revamped, it is a
good place to move that EO API for now.
Ref T5363
This is also another protected and beta API. Meant to be overridden by
subclasses, but belongs to a still unstable API.
The difference between the internal legacy and the EO API is really bad.
Same as with activate (previous commit).
Ref T5363
Also prefix with widget.
I want to rename this as child rather than sub. It's inconsistent with
the other parent/child hierarchies. Anyway the various hierarchies are
confusing, so let's keep this name :)
Ref T5363
This factorizes the code and makes most widgets handle key down events
in the same way:
- check that the object is not disabled, event is not on hold
- figure out the key binding based on the class name
- mark event as on hold
The class name is usually MY_CLASS_NAME but in some cases it was
MY_CLASS_NAME_LEGACY which may be different from the EO class name (eg.
elm_win vs. Efl.Ui.Win). In that case the key bindings are broken.
This breaks key bindings for the following widgets:
- Win (focus)
- Image ("clicked")
- Video (move, play)
This fixes key bindings for the following widgets:
- Nstate
Some widgets remain broken:
- Photocam / Efl.Ui.Image.Zoomable
A patch will be applied to restore the key bindings for the above
breaks.
This is an internal function that should probably become an overridable
protected method, as it's required for proper event handling in widgets.
Next step: use eo_event_info in the widgets implementations. Then remove
legacy event struct.
Ref T5363
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
elm_layout_sizing_eval() marks an object as requiring recalc.
Unfortunately, it's been massively abused by various widgets into
actually doing the calc, or the min calc. So we end up with one API
that has 3 different definitions depending on the widget type:
1. Mark as requiring recalc (correct, respects doc, elm_layout)
2. Calculate min size and other size hints
3. Actually do some geometry modification
I believe we need to clarify these 3 requirements into 3 very clear
and specific APIs in elementary. Right now we have similar functions
in evas for 1 (evas_object_smart_changed) and 3 (smart_calculate).
But their exact definition also isn't necessarily what we want for
elementary.
Another clear problem is that layout_eval does not do any calculation
(in theory), so the "eval" word is a bit of a stretch here.
Once we're sure about the exact API we want, we can add this back to
EO and make it work across our EO widgets. For now let's just keep
the legacy API, and its EO overrides, as is.
Ref T5315
We need focus edje signal when item is focused or the already
focused item realizes. its wrong to call focus signal on
_elm_genlist_item_state_update()
fixes T4969
this fixes a bug in genlist when scrolling is enabled and
items at top and bottom are disabled. Focus behaviour is not normal
in case up arrow is pressed when focus is at the top enabled item
or down key is pressed when focus is at bottom enabled item.
fixes T5576
this seems wrong since it's using smart object geometry to determine
event-based positioning within an edje object. considering it from a user pov,
it definitely is wrong because why would you deselect items based on mouse
movement?
ref D2622
ref da81eff897
@fix
Summary:
There are several problem is left on recursize content calc.
previously genlist only calculate size of layout class,
but after recursive content group calculation patch,
layout couldn't get proper size because sizing eval is
not pre-processed.
Test Plan: elementary test working fine.
Reviewers: jpeg, cedric, raster, conr2d
Differential Revision: https://phab.enlightenment.org/D4952
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
Genlist item doesn't change its size when its content size is changed,
but its size is determined in realization.
Therefore, deferred calculations for content should be performed immediately
before swallowing it by genlist item.
Test Plan: make and run attached sample
Reviewers: jpeg, SanghyeonLee, cedric
Differential Revision: https://phab.enlightenment.org/D4705
elm_widget_theme_object_get now return Elm_Theme_Apply enum not bools.
only ELM_THEME_APPLY_FAILED case, need to re-apply default item edje.
Signed-off-by: SangHyeon Lee <sh10233.lee@samsung.com>
Summary:
When _item_filtered_get is called, block and pan re-calculations
happen, When there is no filter applied, we can skip item filtering to
avoid some unwanted calculations
Reviewers: cedric, raster, SanghyeonLee
Reviewed By: raster
Subscribers: rajeshps, Princekrdubey, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4759
The item, after having been unswallowed from its decorate
item, becomes unclipped and unparented. The parent was well
reset, but the clip wasn't.
Test case:
elementary_test -to "Genlist Decorate Item Mode"
I'm sure some bugs are still lurking. Genlist is so lovely.
Fixes T1551
In "Genlist Decorate Item Mode" after decorating a few items
(rotate or slide, doesn't matter), only one item or none should
be decorated. Scrolling up and down the genlist should work just
fine. This fixes massive render issues and inconsistent states
of the items in this test case.
"rotate" mode is still going nuts.
Ref T1551
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
Andrii Kroitor
Lukasz Stanislawski
Lukasz Stanislawski
Godly T.Alias
Marcel Hollerbach
SangHyeon Jade Lee
SangHyeon Lee
Jeeyong Um
Carsten Haitzler
