with the previous commit we emit the legacy events for each interface
event, and thus this event is not needed.
However, in elm_entry this means that changing editable will _not_
reemit the focus event (where i am not that sure if that is correct or
not).
This region has little to do with focus, as it's more of a region of
interest within the widget, and not directly related to the highlight
geometry, for instance. It's related to focus in the sense that only
widgets with focus would really care about this region.
I decided to change this name after talking with @bu5hm4n.
Note that gengrid uses this but is also completely broken (the focus
highlight floats around and you don't even see the focused item).
Note: This is very close to show_region but I'm not sure those can be
merged safely (since the default "focus_region" is NULL while the
default "show_region" is the widget's geometry).
Ref T5363
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.
Adds "Efl.Ui.Text_Async" object.
This new widget uses the "async_layout" functionality of the underlying
Efl.Canvas.Text object.
Currently, if "editable" mode is enabled, there is no asynchronous
layout, as interactive operations (e.g. typing) should get processed
immediately. Thus, only "non-editable" instructs the text object to do
asynchronous layout.
@feature
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
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
It's not beta. It's about to die.
Also, move #define ELM_WIDGET_BETA to the common header file, as it is
consequently required by ALL widgets. :(
Ping @bu5hm4n :)
Ref T5363
Renamed to on_disabled_update.
Also passed in the new state of disabled. It's more convenient this way,
than having the subclasses call disabled_get.
Also simplify some code...
Ref T5363
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
This removes an argument that was false only for a single widget:
naviframe. Hopefully this logic is now simpler, even though it involves
a small hack within naviframe itself.
Ref T5363
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
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
Changes cursor handle name from 'Efl.Text.Cursor.Cursor_Data' to
'Efl.Text.Cursor.Cursor'.
Also, replace all usages of Efl_Canvas_Text_Cursor
with Efl_Text_Cursor_Cursor as the handle for the cursor.
Amitesh Singh
Marcel Hollerbach
Jean-Philippe Andre
Lukasz Stanislawski
Marcel Hollerbach
Lukasz Stanislawski
Daniel Hirt