Dereference null return value issues is reported by Coverity.
If `sd` is NULL, it will return zero values.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9668
Parameter of `eina_spans_intersect` are pairs of point and length.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9655
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
the buffer was accessed with the wrong id, buffer_id should be used.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9607
this makes the group items stick at the top of the viewport, if the
corresponding items in there do have the item available.
For now items between two groups are not really handled, the group
header will still just be displayed.
The code for this feature is explicitly written in a single block, it
was said that we might want to have this able to be enabled / disabled
later on.
This commit also shuffels the code here a bit, one single method just
got too long.
ref T8115
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9587
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
this brings a group item in the style of genlist / gengrid group items.
The group item theme does currently not provide the signals in the theme
that would be needed for selecting it. This is kind of intended, but we
might need API to express that.
ref T8115
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9583
these parts are hard copies of the part implementations given from the
layouts. Replacing them with the layout implementation just works
ref T8115
Differential Revision: https://phab.enlightenment.org/D9582
default item is used as base class for all "normal style" efl items.
A "normal style" efl item does have a text,content & extra part.
- The text part is usally used to express some text in the item
- Content part is the *main* content part where the user attention is
on.
- Extra can be used to display some elements that are not directly
getting the attention of the user, it can be seen as something more than
the decoration item field.
ref T8115
Differential Revision: https://phab.enlightenment.org/D9629
ensure that setting user hints on this object triggers a recalc
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9651
this is used for storing the position and size of the widget. However,
just in elm_test this eats 2KB of ram, just for saving them. The cases
where they have been used do not seem like a great performance hotspot,
additionally, in the panel cases the privat data of the widget is
achived anyways, so eo is involved and we are spending some time there
anyways.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9646
walking here the parent chain can be very costly, esp. if you make a lot
of widgets visible or hide them. With this commit we ensure that we only
walk the parent chain when there is a custom chain, which is only the
case in legacy. This gets us about 2-3 FPS on the rpi with the
item_container benchmark.
With earlier commits, tree_unfocusable and disabled is honoring the
whole parent chain, so checking that alone, without the parent chain, is
fine.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9645
Before this patch tree unfocusable set just set a simple flag, getting
this state however forced you to traverse the whole parent chain to get
the real result.
With this patch the setting of the unfocusable flag is heavier as it
walks all the children of the widget, however, the getting of the flag
is way easier now. The next revision will refactor the focus related
APIs for that.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9644
asking for a parent provider only makes sense if we are having a custom
focus parent provider, otherwise this will just result in the normal
parent relation. Not doing this safes us a lot of time that we spent for
nothing in the focus evalulation code.
The gengrid change is needed as the parent provider should be applied
after the constructor is called, otherwise there is no garantee that
shared_win_data is not NULL.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9643
this introduces a shared place to all widgets. The shared pointer is
allocated in the window, as the window outlifes every widget that is
part of it.
This struct will be later used for further optimizations like:
1. There are really heavy focus operations which are only needed for
gengrid/genlst, there is no point in executing them if there is no
gen**** added to the window object. So we can skip the custom
parent_provider logic that is only introduced for gengrid / genlist.
2. Legacy focus APIs must do list walks, which means, on every focus
operation we always have to walk the full list up to the parent, which
is annoying and slow, as we *most of the time* do not use legacy focus
API.
This list can be continued, the above two cases are fixed in the next
revisions.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9642
Summary:
scrollbars (and other parts) can have min sizes which affect sizing calcs,
so it's necessary to ensure that these signals are processed before trying
to size in order to get the correct size
Depends on D9593
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl_widgets
Differential Revision: https://phab.enlightenment.org/D9594
Summary:
This commit includes follwoing works.
1. change parent class from EFL_UI_SLIDER_INTERVAL
to EFL_UI_LAYOUT_BASE
2. get all necessary codes from efl_ui_slider and
efl_ui_slider_interval to elm_slider
3. add callbacks to slider test code
ref T7893
Test Plan:
1. elementary_test
2. slider
3. operate sliders on the window
Reviewers: bu5hm4n, segfaultxavi, eagleeye, zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7893
Differential Revision: https://phab.enlightenment.org/D9623
calling geometry set here is again calling the API in canvas object that
splits this call to size_set and position_set which means we spent quite
a bit of time in eo, just to call the same APIs we could call directly.
With this commit here, the calls are directly going to the right
objects, with the right API.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9619
if we are heaving a streak of showing / hiding a lot of widgets we free
and calloc the same nodes all the time. This now lowers the amount of
callocs / frees that we are doing
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9618
otherwise we would need to get the private data of the focus manager
which is quite a heavy operation. This is slowing down enormously the
visibility setting of widgets.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9617
if there is high frequency adding and deleting of items, the deletion
here can be quite heavy, this makes freeing a little bit faster.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9616
the internal text object provides a min size based on its current geometry,
so temporarily match the geometry of the overall object in order to provide
a somewhat more accurate calculation sooner for this object
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9598
efl_ui widgets should not use legacy widgets internally
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9596
this fixes setting scroller properties during construction
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9593
this is the time when all calculations need to be handled, so ensure that the
widget directly updates itself here instead of deferring in order to avoid
infinite recalc loops
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9592
this is already handled elsewhere and can cause infinite recalc loops
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9591
hoversel doesn't implement group calc or do any sane type of sizing
so just manually call these on demand to ensure the correct size is used
fix T8127
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9632
the hoversel must be created before it can be shown, and its internal
hover object may be destroyed when it is hidden
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9631
Summary:
integrate mman.h to make Evil private to the EFL, as mman.h does not exist on Windows. After a discussion with raster, i include sys/mman.h only on non Windows platform.
One issue, though, is that src/modules/emotion/generic/Emotion_Generic_Plugin.h has inlined functions using mmap()
Test Plan: compilation on Windows
Reviewers: cedric, raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9542
Check whether we called `efl_part_get` before.
This was happening to C# bindings (maybe a bug there?) but in any case a
failure is safer than a segfault.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9563
these function the same as the min size hint versions and enable
distinction between internally-set max size hints and user-set max size
hints
@feature
ref T8122
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9553
this is more or less just the max size hint, so just set the max size
hint
ref T7902
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9550
this was more or less just a wrapper around efl_gfx_entity_size_set
and resulted in unpredictable behavior depending on when it was called
instead, simply set the min size hint on the popup object
ref T7902
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9549
Summary:
canvas objects do not need localization because they are not directly user-facing
this should only be inherited by objects which need to be localized
Depends on D9559
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9560