Summary:
All legacy @since tags have already moved to the *.legacy.h files.
EO files are now devoid of @since tags (except some eldbus still
needed for legacy).
Upcoming patches will add @since 1.22 to those APIs which come out
of beta in this release.
APIs marked @beta do not need @since tags.
Test Plan: Everything builds, EO docs (like DocFX) have no Since tags.
Reviewers: zmike, bu5hm4n, lauromoura, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8430
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:
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
Now you can't use the same syntax as you would for a method to
implement a property as whole, instead you need to specify the
getter and/or setter explicitly. This is to allow parent classes
to expand their properties without altering behavior of the child
classes.
Previously we couldn't return a slice, instead required the user to
pass a slice and we'd fill it since Eolian couldn't generate fallbacks
for structures.
Since @q66 fixed eolian, we can now return the structure itself as
initially wanted, ditching some TODO from the code.
While using efl_io_queue + slice_get I found that we need to discard
data and the only way was to read to an actual buffer, kinda annoying.
Then introduce a discard method to do that.
The use of low-level interfaces such as Efl.Io.Reader and
Efl.Io.Writer are not that user-friendly as they can handle partial
data.
Classes such as Efl.Io.Copier makes them easy to use, but they need a
reader (source) or writer (destination) and in our examples we used
fixed buffers or some existing streams (stdin/stdout/stderr,
networking...).
However, if interactively we need to produce some data to be sent,
such as implementing some networking protocols, we'd have to write our
own Efl.Io.Reader and Efl.Io.Writer classes to handle the buffering.
Not anymore! With Efl.Io.Queue you can write stuff to it and it will
buffer to memory. Once stuff is read, it will automatically remove
those bytes from buffer.
Xavi Artigas
Marcel Hollerbach
Cedric BAIL
Andy Williams
Daniel Kolesa
Gustavo Sverzut Barbieri
Stefan Schmidt