Summary:
if the layout object does not exist here then there is nothing to freeze
@fix
Depends on D8980
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8981
Summary:
this fixes a huge number of errors during object deletion
@fix
Depends on D8979
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8987
Summary:
this can never succeed as there will never be an object to successfully
size with at this point
@fix
Depends on D8954
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8955
Summary:
this has no effect since the resize_obj is what determines sizing
@fix
Depends on D8953
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8954
Summary:
And the Efl.Orientation interface -> Efl.Gfx.Orientable
(with proper c_prefix so it is not too cumbersome to use from C).
Also, turned the theme_rotation_apply() parameter into an int to avoid confusion.
Fixes T7919
Depends on D8912
Test Plan: Everything continues to build and pass tests
Reviewers: zmike, bu5hm4n, cedric, Hermet, Jaehyun_Cho
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7919
Differential Revision: https://phab.enlightenment.org/D8926
something else might cause the object to get magically revived. Once the
object is invalidated, some things are able to set a parent again, which
causes the widget to continue with refcount 1 and a parent.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8637
since commit a1addad60e, To add myself as a sub object of parent object will be
done in Efl.Ui.Widget constructor.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8280
This reverts commit cced5487c8.
This patch was pushed just to silence warning without fixing the problem and doing
something that was incorrect (coupling an efl_del with an efl_ref).
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8429
Summary:
fix Eina_Error type calculation in _efl_ui_layout_base_efl_ui_widget_theme_apply() to behave as before.
@fix
Test Plan: run elementary_test for all widgets
Reviewers: #reviewers, Jaehyun_Cho, Hermet
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8443
Summary:
Because `efl_isa` doesn't call _efl_object_call_end, the part object is not
removed. it occurs a bunch of efl_unref error message.
Test Plan:
1. elementary_test -to 'efl.ui.box'
2. exit window.
3. check there is no efl_unref error message.
Reviewers: zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8385
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8166
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8142
Summary:
now that the error codes have been change to be compatible with eina_error,
this can be removed and will work through eina_error naturally
fix T7718
Depends on D8067
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7718
Differential Revision: https://phab.enlightenment.org/D8068
Summary:
this can be mimicked with efl_provider_find as the top widget should
always be efl.ui.win
ref T7553
Depends on D8063
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7553
Differential Revision: https://phab.enlightenment.org/D8064
Summary:
this swaps the values of "no error" and "error" in order to maintain
consistency with the rest of efl where the zero value means "no error"
Depends on D8060
Reviewers: cedric
Reviewed By: cedric
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8063
efl_content leave the caller in charge of the lifecycle of the object. This means we can
rely on the factory to actually do something with the object before it is destroyed by anyone.
Reviewed-by: Vitor Sousa da Silva <vitorsousa@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D8091
Most of classes implements Efl.Container.content_remove are just calling "unpack"
except of "Efl.Canvas.Layout" and "Efl.Ui.Layout".
This patch remove the asymmetrical API and add content_remove API of
"Efl.Canvas.Layout" and "Efl.Ui.Layout" that child can be remove without efl_part
APIs.
ref T7576
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D7913
before the disable property was a bit weird. Setting something to
disabled=true will disable all children of the widget that is changed.
However, only the update function of the children will get the false flag,
not the flag itself. Which means, to query the real disabled state, we
need to walk up the parent relations.
With this patch, every change to disabled will go through the disabled
property, which mean, a implementor can just overwrite the disabled
property, and adjust its internal state there. Just be carefull, a set
to disabled=true still might result in disabled=false. This makes the
function on_disable_update unneccesary. Which also cleans up the
Efl.Ui.Widget class.
ref T7553
Depends on D8016
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8017
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:
the previous implementation/api had a number of issues:
* "file" property contained both "file" and "key" values
- also performed file loading operation
* "load_error" property which was specific to image objects
* no methods for controlling file loading/unloading
this patch attempts the following changes:
* split "file" property into "file" and "key" properties
- also remove "key" from existing "mmap" property
* remove "load_error"
* directly return error codes from operations
* add "load" and "unload" methods for directly controlling load state
* add implicit file loading if file/mmap is set during construction
* rewrite all efl.file implementations to move file loading into load() method
* rewrite all usage of efl.file api based on these changes
* add C extension functions to mimic previous behavior
ref T7577
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: vitor.sousa, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7577
Differential Revision: https://phab.enlightenment.org/D8018
this existed only to provide the methods for Efl.Ui.Layout_Part and fill
in implementation for some legacy functions which should probably not be
supported going forward
the corresponding methods have been merged into efl_ui_widget and the
legacy functions no longer use eolian-generated implementations
Reviewed-by: WooHyun Jung <woohyun0705@gmail.com>
Differential Revision: https://phab.enlightenment.org/D7899
As we discussed in T7469 with V40,
efl_ui_model_connect
efl_ui_factory_model_connect
need to be renamed to
efl_ui_bind_property
efl_ui_bind_factory
for this work,
Efl.Ui.Model.Connect interface is changed as Efl.Ui.Bind,
and bind_property and bind_factory both method is supported by this interface.
bind_factory need Efl.Ui.Factory,
and Efl.Ui.Factory inheritted Efl.Ui.Bind,
so I little bit concerned about circular referencing, but so far, it works well.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7529
the obejct used in D7740 have been false.
Here comes the fix + a few tests.
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7746
this is just proxying the method calls onto the inner edje object
ref T5719
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7740
If we are to choose Efl.Ui.I18n for the internationalization support, the localization API
should be named accordingly L10n.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7507
Fix bugs on Views and Model related with null items and proper ownership and
life-cycle of components.
Configure default theme for default factory on finalize.
Add new feature to specify signal connection to boolean properties of Models.
This also fix some '%v' substitution problems.
Parsing EINA_VALUE_TYPE_BOOL as boolean in Efl.Ui.Layout signal updates from
Models (instead of EINA_VALUE_TYPE_UCHAR). UCHAR no longer has special handling
and falls to the general result of eina_value_to_string() as other types do.
Use EINA_VALUE_TYPE_BOOL instead of EINA_VALUE_TYPE_UCHAR to signal selection on
click events to the Model.
Update examples to make usage of the new property connection feature in order to
model selection of items on Views.
Summary:
Efl.Ui.Theme class is required to support language bindings.
Efl.Ui.Theme works based on current elm_theme features.
This patch fixes T7357.
Reviewers: segfaultxavi, cedric, lauromoura, woohyun, zmike, SanghyeonLee
Reviewed By: segfaultxavi, SanghyeonLee
Subscribers: SanghyeonLee, herdsman, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7357
Differential Revision: https://phab.enlightenment.org/D7244
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
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.
Summary:
when set/unset icon and text,
signal "elm,state,[part],visible/hidden" is emitted.
This is wrong because visible/hidden should be handled by
Efl.Gfx.visible, not Efl.Text nor Efl.Content.
This should be changed into elm,state,[part],set/unset"
All relating edc should be fixed.
Test Plan: run elementary_test->button, Efl.Ui.Button
Reviewers: jpeg, cedric, woohyun, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5798
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
This is a follow-up to a44ae48df811ff2bd085da86db1688c0f387efc4.Need to
undo the markup_get call, so that the correct code path
(_efl_ui_layout_text_set) is used. Legacy checks are in that code path.
ref T6642
Commits c07a40c745 and
429e19563d tried to fix markup retrieval by
creating a different code path for the setter and getter. However, legacy code
paths needs to be taken into consideration.
This commit fixes legacy widgets (like guide text that did not show any text
in the entry at the top of 'elementary_test').
ref T6642
The elm_layout_text_get is using efl_text_markup_get by following commit.
commit c07a40c745
elm: make elm_object_text_get return markup info as well.
This commit solves following issue
https://phab.enlightenment.org/T6642
If I set object text as below
elm_object_text_set(btn, "Some<br>text");
then elm_object_text_get(btn) returns "Some text" not "Some<br>text".
So using efl_text_markup_set makes sense.
This commit solves following issue
https://phab.enlightenment.org/T6642
If I set object text as below
elm_object_text_set(btn, "Some<br>text");
then elm_object_text_get(btn) returns "Some text" not "Some<br>text".
Summary:
For now, how to check whether a widget is legacy or not
is to check flags in private data or static flag, which is set
during elm_legacy_add.
If Efl.Ui.Legacy interface is added, it can be easilly checked
by efl_isa(obj, EFL_UI_LEGACY_INTERFACE)
Reviewers: woohyun, jpeg, cedric, Jaehyun_Cho
Subscribers: conr2d, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5748
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
This fixes some of the warnings generated by calling functions on NULL
objects. One of the main remaining points is to avoid unwanted warnings
on non-existing parts.
Ref T6326
This allows to safely verify if a part exists, without triggering any
potential call to NULL object, or even requiring the efl_part() handle
to be created.
This is perfectly equivalent to edje_object_part_exists(), but
implemented by both edje object and elm layout.
Summary:
Change name of 'grid' to 'table' for matching on common ui naming
and avoiding confusion with 'gengrid' and 'grid view'.
grid will be introduced as grid image view after.
Test Plan:
checked make & make install
checked make check - there are errors but not related with these changes.
checked make examples - there are errors in cxx but not related with these changes.
checked make discheck - failed
test in elementary_test with Efl.Ui.Table and Table_static.
Reviewers: raster, cedric, jpeg, felipealmeida
Differential Revision: https://phab.enlightenment.org/D5668
This makes it possible to very easily create drop shadows and glow
effects on any widget. This is absolutely not optimized, though the main
performance bottleneck is that the proxy images get redrawn after just
moving.
@feature
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.
See previous commit :)
Note: right now the background part has a small 3d indent which comes
from the legacy theme being used. This will be fixed soon.
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
Also implement markup_set/get for:
- Efl.Ui.Frame
- Efl.Ui.Slider
Users may choose between text_set/get and markup_set/get, depending on
whether they want to escape their text or not.
This moves the API entry points from Widget to Layout parts. I don't
think the other widgets support translation, but that is easy to fix.
The actual code implementation remains in elm_widget.c.
Legacy-only widgets are covered by Part_Legacy, while all EO widgets
that have text inherit from Layout (except Win but I don't think the
window title was translatable in legacy).
This removes 2/3 remaining part APIs from Widget.
Ref T5363
This relies on the new edje API that gives us the exact type of a part.
This fixes the shortcomings of edje_edit_part_type_get() and returns a
proper Text part type for efl_part(slider, "elm.units.max").
See previous commits:
"edje: Add part_type_get API"
"elm: Split off text and content for efl_part"
Reasons:
- This API has been confused with the min size of the widget, resulting
in badly laid out applications.
- The EO API was not very nice (Range is about numbers, the Gfx size
hint in a part is really ugly).
While I understand the value of this API and how it can be used in
scalable applications, it is in fact not absolutely necessary.
Alternatively to that span size, the widget min size can already be
defined from the application side, or the widget can simply be expanded
to fill in its parent.
This can obviously be reinstated later if the need arises for EO. For
now, keep this feature as legacy-only.
This is VERY tricky.
For legacy, just create an internal class that has both. It's easier
this way. For parts that are handled by Layout directly, we know from
Edje which type to return.
For EO objects we should know from the part name which kind of part we
are dealing with:
- text (overridden by the widget)
- content (overridden by the widget)
- special (new efl_part based functions)
- generic (handled by Layout)
Note: Efl.Ui.Slider was handling "span size" on ALL parts. That's bad...
This is now limited to "span" only.
This means that ALL part handles inherit from the base part class
Efl.Ui.Widget.Part. Layout is the only exception where Efl.Part is
specially overridden.
This is a first step towards generic part APIs, including background in
all widgets.
the content unset in some cases - specifically terminology seems to
put the item back in and doesnt remove it... causing it later to be
deleted if unset to remove it and re-use it (which is rarely done).
@fix
In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
Ref T5315
Ref T5306