All widgets copy&pasted the same description, including an invalid reference
to "Layout", which should be "Elm_Layout".
SOME of them had been fixed over the years but this commit fixes all of them.
This significantly reduces the number of Doxygen warnings and adds meaningful
links to the docs.
previously this would always queue a recalc when calling thaw even if the
object hadn't changed
also mimic edje internal behavior with unsetting 'frozen' during force calc
for possible future handling even though it has no effect presently
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11628
in the case where a layout object was created and had a theme manually set
with efl_ui_layout_theme_set() during construction, the layout would then
call theme_apply() a second time internally during finalize which, if the
theme has not changed (as can only be the case if this flag is unset),
results in a repeated theme_apply for the existing theme
@fix
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10738
Summary:
if a legacy widget calls evas_object_size_hint_min_set, this actually sets
efl_gfx_hint_size_restricted_min now, which is supposed to be the hint that
is used internally by widgets. as a result, there is a conflict between the
size which the user expects and the size which the widget tries to calculate.
the user size should always be respected, however, so this adds some tracking
to determine whether the layout's min size was set by the layout during its own
calc or by something externally
@fix
Reviewers: eagleeye, CHAN, woohyun, Jaehyun_Cho, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10373
Summary:
the theme version isn't available until the theme has been applied, so
we can create an array of all the pending signals and defer them until
such time as we get a theme or destroy the object
this is internal and can be reworked at a later time as needed
ref T8231
Depends on D10157
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8231
Differential Revision: https://phab.enlightenment.org/D10164
Summary:
this throws error and warning messages if the theme api version does
not match the current efl version, and it will cause unit tests to fail
when the theme version is not updated
ref T8231
Depends on D10093
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8231
Differential Revision: https://phab.enlightenment.org/D10081
this is already handled by edje, all we really want here is a flag
to avoid more eo lookups internally when calling canvas_group_change
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10079
Summary:
this function should never need to be called on new widgets
Depends on D9440
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9441
Summary:
this removes elm_layout_sizing_eval entirely from the implementation
hierarchy of any efl_ui-based widgets, ensuring that future code will
correctly use efl_canvas_group functionality
Depends on D9439
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9440
Summary:
this functionality forces group_calc on a layout's subobjects during
layout group_calc so that the layout's own group_calc will yield consistent
and correct results
currently this is only used in panel widgets
Depends on D9437
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9438
Summary:
this feature is set on objects which inherit from layout_base in order to
allow automatically application of variable finger sizes based on a
widget's needs
an example of this would be a calendar, which is 7:8 fingers
this functionality is disabled by passing 0,0 as the property
@feature
Depends on D9436
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9437
This means that this will work nicely with model provider too.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9291
The new api is moved into either Efl.Ui.Win or Efl.Ui.Layout.
Only Efl.Ui.Layout is interested in the rotation, as this is the only
widget that can actaully apply it to the theme. The value itself however
is unique to the window, which means, the window is the only point where
the rotation is stored, and this is the point, where rotation changes
are brought to the layouts.
ref T7553
Depends on D8014
Differential Revision: https://phab.enlightenment.org/D8015
Summary:
most widgets inherit from layout to provide implementations for common
functionality such as content/text/theme get+set.
one of the things that layout also brings into its inheritance hierarchy
is efl.file and implementations for its methods. this becomes a problem
when the widget which inherits layout also wants to provide implementations
for efl.file methods (e.g., entry, which uses efl.file to load text files)
as it will result in calling all of the efl.file implementations up the
chain.
in the case of entry, this could result in the 'file' property eventually being
set to the current theme file in use by the entry's layout object, and then the
entry will attempt to autosave its content to the default theme file when it is
destroyed, corrupting the theme file and breaking everything
to solve this:
* efl.ui.layout remains an instantiable class which implements efl.file
* efl.ui.layout_base is the abstract class which provides all the methods of layout
but should be inherited by all widgets which want to implement efl.file functionality
Depends on D8018
Reviewers: bu5hm4n, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8032
Summary:
Efl.Ui.Layout namespace is removed to keep consistency with other
widgets.
Consequently, "Efl.Ui.Layout.Object" is renamed to "Efl.Ui.Layout" and
"Efl.Ui.Layout." is renamed to "Efl.Ui.Layout_".
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers, SanghyeonLee, woohyun
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7291
theme_klass: set/get klass name used for resize_obj
theme_element: set/get group name used for resize_obj
theme_style: set/get style name used for resize_obj
element_update: automatically sets and apply theme for
sub object of widget.
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
Efl.Model.Container and Efl.Model.Item to efl/interfaces are used
to create Efl.Model objects with predefined property values.
This is useful to any situation where we want an Efl.Model with
explicit defined property values.
Efl.Ui.View and Efl.Ui.Factory are used to connect Efl.Models with
Widgets, Elm.Layout and Efl.Ui.Image has changed to use news interfaces
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Xavi Artigas
Mike Blumenkrantz
Cedric BAIL
Jaehyun Cho
Cedric BAIL
Felipe Magno de Almeida
Sungtaek Hong
Carsten Haitzler
Jean-Philippe Andre
Larry Jr
Tom Hacohen