Summary:
these hints are not strictly size-related, so renaming them is more consistent
with their actual function
ref T7563
Depends on D7968
Reviewers: segfaultxavi, cedric, bu5hm4n
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7563
Differential Revision: https://phab.enlightenment.org/D7977
Summary:
Instead of surrounding all the #include "*.eo.h" lines in Efl.h
with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark
all classes as @beta in the eo files.
This will allow taking them out of beta one by one as we deem them stable enough.
Otherwise, the current procedure involves moving the #include line out of the
ifdef block, which is cumbersome and messes include order.
Depends on D7950
Fixes T7692
Test Plan: Nothing changes
Reviewers: zmike, bu5hm4n, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7692
Differential Revision: https://phab.enlightenment.org/D7951
Summary:
to move_to_top and move_to_bottom since the previous names seemed to indicate
that the object only moved one step instead of all the way through the top
or the bottom of the stack.
Ref T7560
Test Plan: make && make check && make examples work as before
Reviewers: cedric, zmike
Reviewed By: zmike
Subscribers: kimcinoo, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7560
Differential Revision: https://phab.enlightenment.org/D7934
Summary:
These constructors aren't checked for in the finalize step of the
initialization and may be given the @optional tag.
For C# this means they can be ommitted from the constructor call.
This also adds `Efl.Ui.View.model` as a constructor of
`Efl.Composite_Model` as the finalizer checks for it.
Fixes T7673
Test Plan: make check
Reviewers: segfaultxavi, zmike, bu5hm4n, cedric, felipealmeida
Reviewed By: segfaultxavi, cedric
Tags: #efl, #do_not_merge
Maniphest Tasks: T7673
Differential Revision: https://phab.enlightenment.org/D7855
Summary:
this property can enable the associated window to quit the main loop with
the passed exit code when the window is destroyed
@feature
fix T5494
Depends on D7594
Reviewers: cedric
Reviewed By: cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T5494
Differential Revision: https://phab.enlightenment.org/D7595
Summary:
this property causes the main loop to exit with the passed exit code
when the standby event is triggered
@feature
ref T5494
Reviewers: cedric, bu5hm4n, segfaultxavi
Reviewed By: cedric, bu5hm4n, segfaultxavi
Subscribers: segfaultxavi, bu5hm4n, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T5494
Differential Revision: https://phab.enlightenment.org/D7594
these hints are not relevant to anything but window objects, so put them
onto the window object
ref T5719
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7729
Summary:
Remove unnecessary abstract and class inheritance from eo file because
those abstracts and classes are duplicate.
e.g. if class B (class A) in B.eo file, then class C (class A, class B) in C.eo file.
Reviewers: woohyun, felipealmeida, Hermet, bu5hm4n
Reviewed By: Hermet, bu5hm4n
Subscribers: bu5hm4n, cedric, segfaultxavi, q66, #reviewers, lauromoura, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6982
This reverts commit 4067fafe07.
As commented on D6982, the original patch changes the widget's behavior.
e.g. Efl.Ui.Win cannot be called with Efl.Config_Gloabal APIs.
Elm.Combobox cannot provide events of Button and Hover.
Until the above changes are resolved, the original patch is reverted.
Summary:
Remove unnecessary abstract and class inheritance from eo file because
those abstracts and classes are duplicate.
e.g. if class B (class A) in B.eo file, then class C (class A, class B) in C.eo file.
Reviewers: woohyun, felipealmeida, Hermet
Reviewed By: Hermet
Subscribers: cedric, segfaultxavi, q66, #reviewers, lauromoura, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6982
Summary: I had fixed some typos and some wrong expressions in API reference doc
Test Plan: N/A
Reviewers: raster, zmike, Hermet, segfaultxavi
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6943
The interface efl_part_get should not be directly called from C, but the efl_part
wrapper should. It rely on efl_noref to properly destroy the object. Binding can
control the lifecycle of the reference the way they want by either calling the
wrapper or efl_part_get directly. It also means that the ugly ___efl_auto_unref_set
doesn't need to be exposed outside of EFL anymore.
Differential Revision: https://phab.enlightenment.org/D6098
Summary:
All events must have a type now, otherwise bindings don't know how to handle
the event_info field.
Most of the missing event types were actually "void" (no event_info present).
Some struct definitions had to be moved to eo instead of h files, so they
are available to bindings. Some have not, and are marked with FIXME.
Some namespaces have been fixed (like Efl_Event_Cb -> Efl.Event_Cb).
In general, there are hundreds of changed files, but mostly to add a type which
was not present before, so there's no harm done.
Also, A lot of FIXMEs have been added which should be, like, fixed.
For example, some events can send different types of event_info, which is
very inconvenient (and error prone).
Test Plan: make with c# bindings works, make check and make examples work too.
Reviewers: cedric, q66, lauromoura
Subscribers: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6169
Summary:
The mixin encapsulates the correct
- creation
- composition attaching
- Lifecycle handling
of the focus managers that are assosiated with the object.
This fixes error messages on shutdown, and additionally lifetime issues
where the composite_attached object was deleted before the object was
deleted.
Reviewers: cedric, zmike
Reviewed By: zmike
Subscribers: segfaultxavi, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6108
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.
Mike Blumenkrantz
Xavi Artigas
Lauro Moura
Marcel Hollerbach
Yeongjong Lee
Jaehyun Cho
Woochanlee
Myoungwoon Roy, Kim
Cedric BAIL
Marcel Hollerbach
Mike Blumenkrantz
Jean-Philippe Andre
Amitesh Singh
Andy Williams
Hosang Kim
Lukasz Stanislawski
Daniel Kolesa
Marcel Hollerbach