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
Override mode is not available in the unified api. That's because you
can't do it in Wayland.
I still think those types are stupid and should all die: Win subclasses
handle them for you. Odd types can't be used anyway.
Ref T5322
Unless it's implemented for Wayland as well, AND provides more
information than a NULL event_info, I see no point in this being an EO
event. Keep legacy as-is: a smart callback only.
Also, minor cleanups to the EO file.
Ref T5322
The problem with the API is that it uses an array of ints, which is not
well defined in EO. We could set an array of pointers to int, but that
would be super awkward to use.
I believe the original API has been slightly over-engineered as it was
passing an array of available rotations when in reality only 4 rotations
could be supported (0, 90, 180, 270). It seems to me that the day
arbitrary rotation needs to be allowed, another API would be required
(maybe with a range, or a single bool flag to allow anything).
I have not modified the internal code, which still uses an array (as
ecore evas uses that).
Mote: ec464939d9 removed wm_rotation_supported_get(), as well as
the preferred rotation from EO, but they could easily be added back if
needed.
Note 2: I couldn't test as desktop E doesn't support WM rotations.
Ref T5322
When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
Note: this is C only, not legacy only.
The problem is that bindings will hold a strong reference to the window,
which will then die "under the rug" if autodel is enabled. This then
leads to at least ERR if not crashes.
Note:
elm_policy needs to support autodel and quit on last del only for C
applications. Bindings will require some other mechanism that doesn't
break all assumptions wrt. references.
Refer to the previous commits for more context.
When an evas object is given to a container, be it with a variant of
efl_pack() or efl_content_set(), its "ownership" is given to the new
parent container. But ownership here means that the new container may
delete the child when it sees fit (i.e. when the container itself dies,
for instance). This does not mean that a reference was passed from the
calling context to the container. The actual EO owner of the child is
always the canvas or another canvas object, even if it the object is
unpacked.
Note: This means that invalid calls to efl_pack or efl_content_set will
not automatically delete the child object. This is the same as legacy,
and results in floating objects. Just check the return value! :)
Hopefully this is correct for bindings.
pause event means that the window is not visible anymore to any user.
resume is triggered when the window became visible again or just
became visible again.
Note: The distinction is made on how the window was created, not on
which API is used (evas_object_lower or efl_gfx_stack_lower or
elm_win_lower).
Ref T5322
Note: elm_test "Focus Style" can be used to test this API. The test case
is a bit broken (overly complex EDC?) but if you're patient you can see
the difference between "glow" and "glow_effect".
Ref T5363
Ref T5322
Fake: This should never have had the fake_canvas_set API. It already can
not work after efl_finalize. And Ecore_Evas isn't part of EO API so it
doesn't make sense at this point to try to expose the fake window as
part of EO API.
Socket: This is the only type of window that implements socket_listen.
So we can just move this function to a new subclass.
NOTE: Socket & plug are currently broken, even in 1.20 (at least for me)!
Ref T5322
Summary:
Implement efl_provider_find function for efl_ui_win class.
This will support to search window class by efl_provider_find function.
Reviewers: jpeg, cedric, Jaehyun_Cho, thiepha, woohyun, Blackmole
Reviewed By: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D5045
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
Xavi Artigas
Marcel Hollerbach
Mike Blumenkrantz
Jean-Philippe Andre
Amitesh Singh
Andy Williams
Hosang Kim
Lukasz Stanislawski
Daniel Kolesa
Marcel Hollerbach
Cedric BAIL
Lukasz Stanislawski
Taehyub Kim