These interfaces allows generic operations on objects that can store
or provide data, such as a file or a buffer.
With well defined interfaces and events we can create code such as
Efl.Io.Copier, that will link a source with a destination and
progressively copy data as they appear.
As we add more object in the main loop, they can't live in the top
namespace as they make little sense there (Efl.Fd !). For coherence,
everyone should in the loop namespace, so move timer there.
this is an args event. right now we don't use it, but this should be
done by some of the setup/init of an app and then produce an args
event. the idea would be that this can be used by single-instance apps
like web browsers, terminology to treat launch as an event.
This allow you to monitor fd and get notification using Eo events. I
have not implemented the buffered read as used by X. I think that if
this is useful, we should just do another class to handle bufferred fd.
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c
Now, Ecore.h includes three new files:
- Ecore_Eo.h: Eo API functions (functions defines, enums, base id).
- Ecore_Legacy.h: contains the API functions related to objects
- Ecore_Common.h: common data (structs, enums...) + functions not
related to objects.
This phase is needed for the EFL 1.8 release to disable Eo APIs if we
consider it is not enough mature to be used by applications.