This fixes the issue of zero division when columns is zero.
Sometimes columns can be zero when "pd->viewport.w = 0".
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10768
in position manager grid and list, there are caches for the sizes, so
the access within placing the item is faster. The cache sometimes is
invalidated, which means, it must be rebuild before accessing it.
This commit is the result of reviewing all the accesses, that the
correct item is available.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10065
there are situations where the entity is not ready yet when the initial
placing does happen. With this API you can tell the position manager
that the placing of the items can be reapplied at the entities are
availble now.
Differential Revision: https://phab.enlightenment.org/D9947
prior to this commit, we just passed the start_id and the end_id the
end_id was the start_id plus the size of the memory buffer. However,
making this depending on the size of the memory buffer is a bad idea, as
changing it based on our needs is rather painfull.
With this commit we have explicit passing of the start_id, end_id and
memory len. This is kind of redundant, however, its very convenient, and
easy to write. The buffer will be filled with the maximum size that is
possible with length of the buffer, however, the end_id will not be
filled anymore.
Differential Revision: https://phab.enlightenment.org/D9756
its sometimes possible that there is a NULL object returned by the batch
call. We should not just access the NULL element. Additionally, if NULL
was returned during visibility setting, we need to set visibility here.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9827
we are walking all the items anyways, so we can recalc the minsize here
anyways. Additionally, this pm was never tested with code that just
passes a set of items at data-access init time, without calling
item_added for each item. (Which is perfectly fine). With this commit
this is now perfectly possible,
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9826
before data access has been a property on
Efl.Ui.Position_Manager.Entity. However, we are not sure how stable all
this will be, and maybe we have the demand to change that in future, in
order to allow more high-performance item passing here.
Additionally, this patch addresses a few lectures learned from the past,
that includes:
- direct group header filling.
- direct group sizing
- difference between size for caching, and size for displaying
- Have a end_id which is the maximum of id that is filled.
ref T8179
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9754
This commit introduces the correct placement of group items and normal
items. The gruop items are also floating on the top of there child items
in case they are not visible on theire own. Items without group items
between items with groups are right now a little bit troublesome and
might display the wrong group, we *need* to check later on if this case
is even needed or not.
The whole placement code now uses 2 different caches, one cache is
counting how many groups we have, and how many items each group has.
Additionally, the size of the header + the state of the header is
safes. The second cache does translate that into how much size one full
group needs on the screen to be placed, this makes the calculation of
the correct item placement a lot faster.
The invalidation of the caches is also quite good. The size cache only
depends on the viewport size and the group cache, which means its
*never* recaclulated on a normal scroll operation. Only if items are
added, or the widget is resized (The later case can also be more
optimized). The group cache is only invalidated when new items are
added (Which is normally not happening during rendering)
ref T8115
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9608
every batched call will now contain the id of the first item, if the
conditions in the documentation are met.
ref T8115
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9586
Summary:
the behaviour here is that the next item according to the direction is
getting focused. This sounds easy but is quite complex given the fact
that the items might be hidden. This is the first draft for this, to see
how good it performes.
Reviewers: zmike, stefan_schmidt, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9496
the new event can be used to message back the currently visible range
from the position to the collection / collection_view.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9462
this commit enables access to the item structure of the collection via a
function callback. The function callback now enables batching for items,
which does not pay off right now. However, a few more optimizations can
be done in order to get the whole payoff.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9445
This does the following rename as per T8058:
Efl.Ui.Item_Position_Manager -> Efl.Ui.Position_Manager.Entity
Efl.Ui.Grid_Position_Manager -> Efl.Ui.Position_Manager.Grid
Efl.Ui.List_Position_Manager -> Efl.Ui.Position_Manager.List
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9388
Cedric BAIL
WooHyun Jung
Marcel Hollerbach