This function is meant to be used by the widgets themselves, or internal
features such as elm_access.
Also remove const tag: this function call is definitely modifying the
widget (panning around and all that).
Ref T5363
This is also another protected and beta API. Meant to be overridden by
subclasses, but belongs to a still unstable API.
The difference between the internal legacy and the EO API is really bad.
Same as with activate (previous commit).
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
Renamed to on_orientation_update
This internal / virtual function is in fact not overridden anywhere. Not
sure it is necessary to expose it in EO API?
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
I'm not sure about the name for focus_allow:
- can_focus
- focusable
- focus_allow
- ???
Also, it looks like focus should just be the evas object function
overridden.
Ref T5363
This is an internal function that should probably become an overridable
protected method, as it's required for proper event handling in widgets.
Next step: use eo_event_info in the widgets implementations. Then remove
legacy event struct.
Ref T5363
This is only for EO obviously. style_set and theme_set should only be
called when the object is being created, not after. On-the-fly style
changes are complex to handle and in most cases it should be easy to
simply repopulate the object after creating a new one with a new style.
There are only a few cases where style_set is used long after creation
of an object, like changing how a label slides, or in the evas 3d map
examples. Menu seems to change the hover style a lot, so rewriting it in
pure EO would need some extra work, maybe.
Ref T5307
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
elm_widget APIs are internal only, even if they may be EAPI. The EAPI
here is for modules.
I believe this API is only required for layout objects, so simply should
remain in the layout class. Then you can do efl_isa() and call the
functions or accept error messages if you want to be more careless.
Ref T5363
This is really only a demonstration of what kind of information
we can print with efl_debug_name_get(). Hopefully this can help
debugging with printf/ERR logs and even help with live debugging
inside gdb.
This shouldn't be used for other purposes than debugging, as the
exact string format is not defined.
@feature
according to q66 this is correcter than ptr(..).
Anyhow this still leads to a bug in cxx that crashes compilation in cxx
examples, people are notified!
with this we can whipe out the focus.manager field in elm.widget so for
the case that something goes wrong we only get the error message where
actually something went wrong, and not the whole bunch of follow ups
where the code assumes its registered but it isnt.
This is, unlike what some of the documentation says, a public
API on elm_object. Let's place it along mirrored for consistency,
even if edje object will not implement it.
Ref T5363
Jean-Philippe Andre
Marcel Hollerbach