elm_layout_sizing_eval() marks an object as requiring recalc.
Unfortunately, it's been massively abused by various widgets into
actually doing the calc, or the min calc. So we end up with one API
that has 3 different definitions depending on the widget type:
1. Mark as requiring recalc (correct, respects doc, elm_layout)
2. Calculate min size and other size hints
3. Actually do some geometry modification
I believe we need to clarify these 3 requirements into 3 very clear
and specific APIs in elementary. Right now we have similar functions
in evas for 1 (evas_object_smart_changed) and 3 (smart_calculate).
But their exact definition also isn't necessarily what we want for
elementary.
Another clear problem is that layout_eval does not do any calculation
(in theory), so the "eval" word is a bit of a stretch here.
Once we're sure about the exact API we want, we can add this back to
EO and make it work across our EO widgets. For now let's just keep
the legacy API, and its EO overrides, as is.
Ref T5315
Summary:
In _elm_layout_text_set function, text_signal_emit is called.
But in that case, check text whether it is null or not null before call signal_emit.
So "text" is not null always, and text_signal_emit's parameter "visible" is also always EINA_TRUE.
Reviewers: Jaehyun_Cho, cedric, jpeg
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5049
This merges them with the now standard interface:
Efl.Canvas.Layout_Signal
Some wrapping work was required for legacy API which
takes no user_data in del() but instead returns it. The
new EO function, while harder to use, is more correct
(you can't delete the invalid callback by accident, and
this follows EO events design).
Another crazy wrapping was done in entry/text in order
to add the callbacks to 2 objects instead of just one,
and still return the user data.
As for Naviframe and Popup, those two widgets override
signal_emit to forward the call to another object than
the resize object, but not callback_add/del. So they
are definitely broken.
Ref T5315
Here's the reasoning:
1. We will expose as many edje APIs as possible (and meaningful)
through the elm layout class.
2. Access to internal objects is usually risky, as it allows apps
to bypass EFL in some ways, leading to potentially undefined
behaviours.
3. If the need arises we can still add a similar API back to EO,
later.
Back to #1, it seems that the need for edje_get() was mostly to
call manual sizing functions, or the missing message_send(). I will
make sure these are accessible from the layout itself.
Ref T5315
This makes layout parts implement Efl.Ui.Cursor.
This also adds the missing bool returns from that interface.
This removes 7 APIs from Elm.Layout.
Ref T5315
This is an API enabling accessibility on text(block) parts
in a layout. But it is said to have many issues. I can already
see that it only changes a flag but doesn't trigger any code
to create the appropriate objects, so definitely not fully
working.
According to @kimcinoo this may remain in legacy land for now.
Inside efl_part() we don't know whether we are dealing with a text
or content API, so we can't actually guess the proper alias.
The legacy API should have already dealt with aliasing at this point.
The EO API should not use those aliases.
This in theory should only affect the EO API usage. In EO
we don't want efl_part() to be used for NULL part. In other
words, there is no "default" part in EO objects. Instead, those
functions like text_set or content_set should simply be
implemented by the object themselves.
The legacy API on the other hand will make sure that the
"part" argument is set to a non-NULL value before reaching
this point.
This is a follow-up to a4b79fdbe1.
efl_part no longer supports NULL parts.
NULL text parts are now aliased in legacy code beforehand.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
This fixes call to:
elm_layout_content_set(ly, NULL, obj);
This only affect this legacy API, not the EO interface.
Thanks Dave for the report!
Ref 59081043a8
This affects the legacy content_set/get/unset part APIs. This
should avoid some unwanted ERR messages in case an elm_object_
API is used on an elm widget that doesn't implement said API.
What this does is request the widget for the name of the default
part if NULL was passed in. Since some widgets are not elm_layout,
they have to override the API themselves, which is why I made it
an internal EO API (rather than a series of efl_isa()).
In theory, part should never be NULL when reaching the internal
implementation code in the widgets, at least for content.
In EO, efl_part(obj, NULL) should be invalid.
Ref T5629
Summary:
- elm_entry has elm.guide text part and it can be set by "guide".
- However when using text_aliases_get, this cannot be found.
- Add elm_obj_elm_layout_part_aliasing_eval() internal APIs to make entry
use proper aliases.
Test Plan:
1. Run elementary test
2. Observe search entry has guide text with "guide" part.
3. Run Entry 8.
4. Observe "elm.guide" part also works.
5. Observe "icon" and "end" part works.
Reviewers: id213sin, herdsman, jpeg
Reviewed By: jpeg
Subscribers: conr2d, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4962
The expected usage is efl_text_set(efl_part(layout, part), text);
Same for text_get.
Also, added an example how to make API easier with providing
efl_text_set/get for the widget itself, in efl_ui_button. Please see
this example.
Most of the values were the same, with edje having just a couple
more error codes.
Not entirely sure the prefix Efl.Image is correct for this type.
Maybe just Efl.Load.Error?
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>
This reverts commit 584e17ae84.
After talking to @herdsman (before xmas) we concluded that we
didn't necessarily want a generic version of efl_text_set/get
for elm_layout. Instead, each widget that should have a default
text part should implement text_set/get themselves (very simple).
Note that Efl.Ui.Text somehow does not "implement" efl_text when
looking at the eolian files. It works by composition.
This implements support for efl_text_set() for the default
part (NULL). This also adds support for efl_text_set(efl_part())
for layouts. This should cover a LOT of widgets :)
The next step is to remove Elm.Layout.text but it's used in too
many places at the moment. @herdsman!!
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
Summary:
When a theme is loaded, Elm.Layout updates strings with new theme.
This adjustment will be performed by Edje. (See D4219)
Reviewers: cedric, jpeg
Subscribers: taxi2se
Differential Revision: https://phab.enlightenment.org/D4220
This reverts commit 8a988717e1.
It seems we can't actually inherit from class more than once and neither eo
nor eolian will complain about it. You will just get random weird behavior.
This patch should come back once we have made an interface of edje.
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
Problem: crash in assert() in terminology.
Scenario:
Open Terminology,
Split V by keyboard,
Move mouse to split 2,
Create tab by keyboard
--> abort() in terminology
Cause:
An extra mouse,in event happens during edje_object_unswallow
inside elm_layout_content_unset.
Root cause:
efl_part() in elm_layout had a side effect: edje_recalc on the
edje object. Causing its geometry to be "properly" defined and
the mouse event to trigger callbacks.
Solution:
Avoid calling recalc... somehow.
Conclusion:
Without adding any new API, edje edit provides internally the
information that we want: type of an edje part (for box & table).
Fixes T4221
See T4028
See T3509
elm layout signal handling was all over the place. using 3 different
ways of adding or deleteing signals from the object. it uses either
obj directly, eo_super(obj) or wd->resize_obj. come on. be consistent.
so using wd->resize_obj worked before and now works properly with
sgnal cbs PROPELY deleted unlike before.
@fix
Summary:
if trying to apply incorrect theme, widget apply default theme and return TRUE.
so there is no way to check it really apply correct theme.
To resolve this problem, _elm_theme_set return three type enum
* related history : 4ca3ef4514
* elm_object_style_set is public api, so I didn't change it.
* typedef name [ Theme_Apply ] is temporarily, please suggest better one.
@fix
Reviewers: singh.amitesh, herb, Hermet, cedric, jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4073
When the parameter 'text' is NULL in elm_layout_text_set function,
the sub object data with the same part name is removed
from the layout's sub object list and the function returns immediately.
However, if the text part doesn't exist in the list,
a new sub object data is appended to the list even though the text is NULL.
This patch adds NULL check so the function can return in such cases.
When the parameter 'text' is NULL in elm_layout_text_set function,
the sub object data with the same part name is removed
from the layout's sub object list and the function returns immediately.
However, if the text part doesn't exist in the list,
a new sub object data is appended to the list even though the text is NULL.
This patch adds NULL check so the function can return in such cases.
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.