The string comparison was invalid for full part names. It worked with
the aliases, by chance, not by design.
This got broken by eee60abbcf but using full part names from the
application side was already broken before that.
@fix
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.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
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
Also prefix with widget.
I want to rename this as child rather than sub. It's inconsistent with
the other parent/child hierarchies. Anyway the various hierarchies are
confusing, so let's keep this name :)
Ref T5363
it turns out to be very handy to have a interface for the moving and
border elements, that is unconnected to the way of how widgets are
registering themself.
This for example enables us to get a simple focus manager that just
redirects the call into a internal 2 dimensional data struct
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
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:
The changes of previous patch (4ea7effe70)
are reverted, and item calculation is fixed correctly.
The main reason why hoversel item has wrong size in screen rotation is
that hover doesn't update geometry when the size of target object is changed.
Test Plan: elementary_test -to hoversel
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4556
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
After reverting 8a21384759, I figured out how to move
the main menu back to the border group. This time the menu is in the
framespace and its layout algos have been adapted to allow non-zero
root coordinates.
This is an override of efl_gfx_size_set. Same as before, the
order of operations matter so it is possible that a corner
case will break. In particular, legacy code was:
- intercept
- smart resize (do stuff), super, super, super
- evas object resize
The new code is more like:
- intercept
- super, super, super, evas object resize
- do stuff
But unfortunately this broke elm_widget (read: all widgets) as
the internal resize was done before the object resize. So,
inside the resize event cb, the resize_obj size would not match
the smart object size. >_<
This is an override of efl_gfx_position_set.
As for the other patches, I hope I didn't break anything.
A problem likely to happen is that the super call was inserted
too early or too late in the call flow. For instance:
_myclass_position_set(obj, x, y) {
position_set(super(obj), x, y);
position_get(obj, &prevx, &prevy);
do_something_with_delta_xy();
}
The above code flow is obvisouly wrong, but may have crept in this
patch (such a bug sneaked in inside smart object, breaking
everything at first).
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
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.
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();
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
This allows apps to set the objects min size with hint_min,
while letting the rest of EFL define the minimum size with
rstricted_min.
I don't like the property names much...
This reverts commit ac5a0b7e79.
I added assert(pd == sd) in the modified code and couldn't find
anything suspicious. The proper class is used in eo_data_scope_get().
I also can't find a crash or a bug currently in hover. I know there
was a problem earlier, but that was fixed in 3092e08a83.
Now, if there is still a problem, we should check it carefully.
Pinging @cedric
So, I was storing a single "sd" pointer (class private data)
but using it in two different places, ie. as if it were two
different classes. Crashes happened, complaints were heard.
See T3714.
This fixes T3714
Efl.Part uses a basic inheritance for layout objects, but somehow
this completely falls apart when the child class overrides all
the functions. Weird. I'll check that more.
This touches Edje and also Elementary where part names are used.
This commit blew up in size since now all content part APIs
(get, set, unset) require to use Efl.Part instead.
This is a big refactoring commit, but no logic should
have been changed. Fingers crossed.
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
This removes the conflicts between the different parents and also
indicates that this is to be used internally by widgets and should
not be confused with the normal user visible parent.
It is an internal attribute that should not be used by people
not implementing widgets. Marking it as protected signifies it
as such.