this really needs a better solution since it results in a blank genlist
item space, with the item itself typically located somewhere offscreen due
to caching
the parent/group item is located after its child items in the list of items,
so if an item is appended to the parent's list of items then it must be
prepended to the parent or else it will end up being in the wrong group
@fix
more fixes for the comically unreviewed revision from elm which continues
to cause bugs months after it was pushed
ref 4c86a66f28876b68e92a90c8f741eed1130dd034 (elm)
ref e88423e994
Efl - efl_model_base changed to use eina_promise
Eio - eio_model use efl_model_base with promise
Eldbus - elddbus models use promise now
Elementary - elm_view_list and elm_view_form use new models with promise
updated all related examples and tests
This fixes the segfault reported by Jack.
The problem was that the object was being reparented and thus
removed from the composition and never added back.
The hicolor fallback requirement is handled by efreet
and the usage of fdo is user specified now not by code.
This means the only (theoretical) way this could be a
problem is if the user removes a theme.
This seems like a good tradeoff to remove the overhead
and enable the apps to switch icons based on config change.
This reverts commit b48d3eb04e.
This patch can be occurred performance issue.
update is needed for only non-homogeneous case.
I'll revert patch and update new patch in phabricator for check.
C++ doens't allow empty size structure, empty structure looks harmful.
I've thought about the solution and this patch is my conclusion.
Because I'm not a big fan of elm_prefs,
if you have any better idea then please fix it on your way.
we will remove elm_icon in the future.(only remain it in legacy)
for this, I added elm_image_icon_set API to the elm_image.
it is same as elm_icon_standard_set.
Summary:
In tree mode if parent item is hidden all its subitems should also be hidden.
@fix
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: jpeg, reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D3918
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
*_visibility_apply() functions are called from each *_visibility_adjust()
function. And it is also called from _elm_scroll_scroll_bar_size_adjust().
So, calling *_visibility_apply() functions after calling
_elm_scroll_scroll_bar_size_adjust() is unnecessary.
@fix
Test Plan: N/A
Reviewers: raster, jaehwan, eagleeye, woohyun, cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3914
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
This renames some APIs from Efl.Pack in order to try and
make them more sensible. Feedback welcome.
Also, most APIs now return bool, where false is quite unlikely
to happen.
This moves the part_box and part_table APIs to a fake object
like was done in Edje Object.
This also adds support a few new APIs to those containers,
so they behave exactly like Edje.Object.
This is another implementation bit of "eo_part".
This removes Efl.Pack_Named which had a terrible name,
removes Elm.Container which should have been renamed
Efl.Ui.Container anyway, and introduces an interface
Efl.Container instead.
The hierarchy tree is now changed as objects don't inherit
from Efl.Container (it's an interface, not a regular class)
but only implement it. Obviously it is very easy to
reintroduce an Efl.Ui.Container parent class if we need it,
but I guess it should have some actual logic. It's basically
part of what Elm.Widget already does.
Some function names have been modified to look better in C
with the efl_content prefix.
@feature
As discussed on the mailing list we're taming the icon_standard code.
This means that icon themes are set by the user not the app.
Deprecate all the icon_lookup calls etc and remove the behaviour.
Add a config panel to elementary_config where the theme can be selected.
The definition of where to load icons is now up to the user
(through the configuration of the icon_theme config value)
rather than being defined in code per-app or even per-component
Summary:
The toolbar's box was resized in _sizing_eval(), _resize_job().
In _sizing_eval(), the box was resized according to its minimum size.
And in _resize_job(), toolbar would recalculate it and resize the box again.
If _sizing_eval() was called after resizing the box properly from _resize_job(),
the box was shrank before calling the next job.
If the box's minimum size is needed for calculation in the job callback,
it shouldn't change box's size before the job callback.
@fix
Test Plan: N/A
Reviewers: jaehwan, eagleeye, woohyun, cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3911
Summary :
when mouse up happens, item must be focused, and after that,
select must be called.
current logic, focus is already called inside the select function
and again focus set is called in the end of mouse_up,
so if user new focused widget inside the select callback,
mouse_up forcely take the focus into the item again.
select callback should comes after the focus callback calls
to work properly.
@fix
Box, Table and Grid now belong to legacy land.
Their Evas counterparts are already not installed anymore,
and Efl.Ui.Box and Efl.Ui.Grid are here to replace those
widgets (note: code was initially copy & pasted).
This should fix installed EO files consistency.
- Children are now contents
- Efl.Pack_Layout is now a separate class and
merges Pack_Engine.
- Removed dumb class Efl.Pack_Item
- Updated docs
- Added pack_ or grid_ prefixes to some methods
Untested yet. Will need to add the common 3 classes:
- standard
- homogenous
- homogenous max_size
And then implement a true custom layout function, that
respects weights in a certain manner (need to define it
clearly).
This fixes the linear API usage with a table.
TODO:
- remove internal table (as it doesn't support layout funcs)
- implement multiple layout functions (regular, homogenous, ...)
This reuses the Evas.Box code, since we are still using the
box internally. The flow layout function is far from perfect
(it works well only with items of same height).
This shows how to use specific layouts provided by EFL.
So, since we don't have function pointers, all the solutions
to reimplementing the layout function are quite convoluted:
1. use events
2. reimplement layout func
3. use an extra object
4. use a generic class (non instanciated)
Promises don't apply here (layout will run multiple times).
Problems:
1. Multiple event callbacks will be called, resulting in
potential performance impact, extra events, etc...
Also, there is no way to define standard implementations
that would be provided by the framework.
2. Reimplementation of a function requires extra EO work
(create an EO class, etc...), doesn't allow on-the-fly
change of the layout method.
3. Probably the best solution is to have an object implementing
the layout. But this means creating an extra object along
with the container.
4. To avoid the extra object, use a class, and reimplement
a @class function. This unfortunately requires extra
EO work.
Solution 4. has been selected, but it's not very nice...
This is only a partial implementation, work in progress.
The grid object should be a replacement for evas and elementary's
table and grid. Only the layout of items inside the container
is different, otherwise the API should be the same.
For now, this widget is based on an evas table but the full
layout logic will need to be reimplemented, eventually.
@feature
This should be the only linear packing container.
This replaces: evas box and elm box.
Edje box needs to be kept around for compatibility,
but it stays an EDC object only (for apps).
Lots of things are still to be fleshed out in this
box implementation:
- Simplify smart object / elm widget code
- Maybe stop using evas object box altogether
- Implement other layout strategies
@feature
Mike Blumenkrantz
Yeshwanth Reddivari
Larry Jr
Jaeun Choi
Tom Hacohen
Andy Williams
SangHyeon Lee
Hermet Park
Stefan Schmidt
Ji-Youn Park
Andrii Kroitor
Youngbok Shin
Vyacheslav Reutskiy
Jean-Philippe Andre
Cedric Bail
Carsten Haitzler