enlightenment/efl
enlightenment
/
efl
8
7
Fork 14
Code Issues 13 Pull Requests 3 Projects Releases Wiki Activity
efl/src/lib/ecore/Ecore_Eo.h

137 lines
2.9 KiB
C
Raw Normal View History

ecore: add Efl_Core.h
2017-10-27 17:15:14 -07:00
#ifndef _ECORE_EO_H
#define _ECORE_EO_H
ecore: Split Ecore headers 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.
2013-04-03 07:46:59 -07:00
/* This include has been added to support Eo in Ecore */
#include <Eo.h>
/**
doxygen docs: Proper usage of @ingroup and @addtogroup This patch brings in a lot of docs which were missing before. Unfortunately, this brings along their warnings so this ends up adding more warnings than it fixes. Still, a step in the right direction. @ingroup puts the current block into the specified group, but IT DOES NOT allow opening groups with @{. This was used in lots of places, resulting in misplaced or ignored documentation. @ingroup should be used only in individual docs. For groups we use @defgroup and @addtogroup. Also,this patch adds some small missing docs.
2020-04-14 07:11:04 -07:00
* @addtogroup Ecore_Timer_Group
ecore: Split Ecore headers 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.
2013-04-03 07:46:59 -07:00
*
* @{
*/
ecore: Efl.Timer should be Efl.Loop.Timer for coherence. 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.
2016-06-03 16:01:08 -07:00
#include "efl_loop_timer.eo.h"
ecore: Split Ecore headers 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.
2013-04-03 07:46:59 -07:00
Ecore Exe: Migrate to eo.
2014-08-07 06:57:50 -07:00
/**
* @}
*/
remove elgacy ecore event usage in futures that limit to mainloop only also eina_procmis was not threadsafe so cannto use loops in different threads at all until this was made safe. needed to disable the old ecore_event using code in for ecore futures and create a new efl loop message future and handler instead ... but now a quick experiment with multiple loops in 10 threads plus mainloop have timers at least work. i need to test more like fd handlers etc etc. but it's a step.
2017-12-27 08:19:52 -08:00
#include "efl_loop_message_future.eo.h"
#include "efl_loop_message_future_handler.eo.h"
Ecore mainloop: Add .eo implementation.
2014-06-16 06:24:45 -07:00
/**
doxygen docs: Fix API reference group to Ecore_Eo This patch fixs a wrong group name in Ecore_Eo API reference Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org> Differential Revision: https://phab.enlightenment.org/D11952
2020-06-08 21:56:30 -07:00
* @addtogroup Ecore_Main_Loop_Group
Ecore mainloop: Add .eo implementation.
2014-06-16 06:24:45 -07:00
*
* @{
*/
Revert "Revert the env object because it's broken portability - please redo" This reverts commit d6294fa22b88187e44391c1c8ca64b1ebdf14533.
2019-02-12 12:34:27 -08:00
#include "efl_core_env.eo.h"
#include "efl_core_proc_env.eo.h"
Revert "Revert command line array object because it's broken by design" This reverts commit a57c7f751023fe1d1edeabbf8683574ac7497e5e. I pretty much hate to just revert your revert, but you failed to read my replies, and failed to understand what i was talking about. And YES we talked at fosdem about the platform issue, and do you remember my answer, that back in time this might be the case, today is different freebsd suppoerts setenv, and for windows we have a setenv implementation in evil. And yes, vtorri also created a issue how bad and evil this commit is, however, i still fail to see the issue since setenv unsetenv and clearenv usages are taken as needed. (T7693) The ownership question is answered in https://phab.enlightenment.org/D7516#137367. Can we please get into a state of technical discussions, and not *oh shit, i am going to revert this* this has been in review for a long time, a lots of people have tested it, we discussed things on it, and there was 3 weeks of no reply from you. The issues that exist will be dealed with. Feel free to create tasks if you want :)
2019-02-12 12:34:30 -08:00
#include "efl_core_command_line.eo.h"
Revert "Revert the env object because it's broken portability - please redo" This reverts commit d6294fa22b88187e44391c1c8ca64b1ebdf14533.
2019-02-12 12:34:27 -08:00
ecore - begin moving data into the efl loop data in the object we really should have data inside the loop object, so begin moving it one small thing at a time. this is the basics that will allow multiple efl loops. make an eo efl object and class for fd handlers that is efl loop bound make fd handlers really bound to their parent loop and not global as well as have a nice class/obj. create an message queue per loop and put legacy ecore events on top of it... and a lot more. this is not 100% done, but it's a lot of the core and groundwork. various ecore_timer_add(), ecore_diler_add() etc. need changes. The following still need doing: ecore_timer (internal usage for sure) ecore_idler (internal usage for sure) ecore_idle_enterer ecore_idle_exiter ecore_pollers? (is the new efl loop stuff ok?) ecore_exe (fork/spawn from any thread and track exe from that thread?) ecore_signal code ecore_throttle (should we have a single global too? we have per loop) ecore_app ? (should every loop be given its own argv/argc?) Lots of internal ecore code uses/calls these legacy calls and we should have efl loop replacements and/or use the ones we have The following will bedifferently designed for loop to loop control/messaging/ipc: ecore_thread ecore_pipe
2017-11-08 22:59:04 -08:00
#include "efl_loop_message.eo.h"
#include "efl_loop_message_handler.eo.h"
ecore - start work on efl task/exe/thread this is astart of the work for having a common task class/interface between loops, threads ane exe's so the i/o is all symmetric and works the same way between all of them as well as similarly for launching and knowing when the exit etc. etc. this is not final and not perfect, but it's a start. comments of course welcome
2018-02-20 22:44:11 -08:00
#include "efl_task.eo.h"
ecore - a different take on efl.app class as a super class to efl.loop so the MAIN loop is actually an efl.app object. which inherits from efl.loop. the idea is that other loops in threads will not be efl.app objects. thread on the creator side return an efl.thread object. inside the thread, like the mainloop, there is now an efl.appthread object that is for all non-main-loop threads. every thread (main loop or child) when it spawns a thread is the parent. there are i/o pipes from parnet to child and back. so parents are generally expected to, if they want to talk to child thread, so use the efl.io interfaces on efl.thread, and the main loop's elf.app class allows you to talk to stdio back to the parent process like the efl.appthread does the same using the efl.io interfaces to talk to its parent app or appthread. it's symmetrical no tests here - sure. i have been holding off on tests until things settle. that's why i haven't done them yet. those will come back in a subsequent commit for really quick examples on using this see: https://phab.enlightenment.org/F2983118 https://phab.enlightenment.org/F2983142 they are just my test code for this. Please see this design document: https://phab.enlightenment.org/w/efl-loops-threads/
2018-02-27 04:19:17 -08:00
#include "efl_thread.eo.h"
ecore - efl threads - add thredio class this adds a simple indata and outdata void ptr to begin that you can set on efl.thread objects (set the indata) and get the outdata too to get results. then on the efl.appthread side the indata is set on the efl.appthread before it runs and on quit the thresad can set the outdata on the appthread, and this appears back on the efl.thread object in the parent thread. so you can basically share pointers to anything in and out this way on start/exit in addition to string args etc. the reason i made it an extra class (mixin actually) is for future expansion. sharing more complex data - eina values maybe or objects as long as they are shared objects, and perhaps acting as an interface for calling a function at the other end like ecore_thread_async_call etc.
2018-03-06 03:49:51 -08:00
#include "efl_threadio.eo.h"
ecore - start work on efl task/exe/thread this is astart of the work for having a common task class/interface between loops, threads ane exe's so the i/o is all symmetric and works the same way between all of them as well as similarly for launching and knowing when the exit etc. etc. this is not final and not perfect, but it's a start. comments of course welcome
2018-02-20 22:44:11 -08:00
#include "efl_exe.eo.h"
ecore: rename Ecore_Mainloop to Efl.Loop.
2016-04-21 15:11:32 -07:00
#include "efl_loop.eo.h"
ecore - a different take on efl.app class as a super class to efl.loop so the MAIN loop is actually an efl.app object. which inherits from efl.loop. the idea is that other loops in threads will not be efl.app objects. thread on the creator side return an efl.thread object. inside the thread, like the mainloop, there is now an efl.appthread object that is for all non-main-loop threads. every thread (main loop or child) when it spawns a thread is the parent. there are i/o pipes from parnet to child and back. so parents are generally expected to, if they want to talk to child thread, so use the efl.io interfaces on efl.thread, and the main loop's elf.app class allows you to talk to stdio back to the parent process like the efl.appthread does the same using the efl.io interfaces to talk to its parent app or appthread. it's symmetrical no tests here - sure. i have been holding off on tests until things settle. that's why i haven't done them yet. those will come back in a subsequent commit for really quick examples on using this see: https://phab.enlightenment.org/F2983118 https://phab.enlightenment.org/F2983142 they are just my test code for this. Please see this design document: https://phab.enlightenment.org/w/efl-loops-threads/
2018-02-27 04:19:17 -08:00
#include "efl_app.eo.h"
#include "efl_appthread.eo.h"
Ecore mainloop: Add .eo implementation.
2014-06-16 06:24:45 -07:00
ecore: remove efl_loop_{un,}register from .eo. We have to keep this as an API, but binding do not need to see it at this point. Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de> Differential Revision: https://phab.enlightenment.org/D9297
2019-07-11 15:34:31 -07:00
/* To be deprecated at some point */
/** Please use efl_provider_register instead. */
Revert "fix warnings about redefinting EWAPI etc. due to windows EAPI changes" This reverts commit e2d6691d524e15b0b0673d121e81c0544271617b. This reverts commit c02b796fdb0960411b24576f654a03f0e765a842. This reverts commit 6c969f6b7d59e64e8bdf09a5e535de9561d77535. This reverts commit 74204bccd724fe9dee428056d4710f37bbc2cffb. This reverts commit 1304d9571775ef740ac6b8978ea4a2025a52c99a. This reverts commit 7c85be9674eaa0362b88f01c61107aa6e7c383a2. revert the EAPI changes that break cxx bindings build. sorry :( more fixes needed than i thought
2021-05-26 07:44:41 -07:00
EAPI Eina_Bool efl_loop_register(Efl_Loop *obj, const Efl_Class *klass, const Efl_Object *provider);
ecore: remove efl_loop_{un,}register from .eo. We have to keep this as an API, but binding do not need to see it at this point. Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de> Differential Revision: https://phab.enlightenment.org/D9297
2019-07-11 15:34:31 -07:00
/** Please use efl_provider_unregister instead. */
Revert "fix warnings about redefinting EWAPI etc. due to windows EAPI changes" This reverts commit e2d6691d524e15b0b0673d121e81c0544271617b. This reverts commit c02b796fdb0960411b24576f654a03f0e765a842. This reverts commit 6c969f6b7d59e64e8bdf09a5e535de9561d77535. This reverts commit 74204bccd724fe9dee428056d4710f37bbc2cffb. This reverts commit 1304d9571775ef740ac6b8978ea4a2025a52c99a. This reverts commit 7c85be9674eaa0362b88f01c61107aa6e7c383a2. revert the EAPI changes that break cxx bindings build. sorry :( more fixes needed than i thought
2021-05-26 07:44:41 -07:00
EAPI Eina_Bool efl_loop_unregister(Efl_Loop *obj, const Efl_Class *klass, const Efl_Object *provider);
ecore: remove efl_loop_{un,}register from .eo. We have to keep this as an API, but binding do not need to see it at this point. Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de> Differential Revision: https://phab.enlightenment.org/D9297
2019-07-11 15:34:31 -07:00
elementary, ecore: move efl_exit helper to Ecore.
2017-10-27 16:37:58 -07:00
/**
* @brief Quits the main loop once all the events currently on the queue have
* been processed.
*
* @param[in] exit_code Returned value by begin()
*
* @note This function can only be called from the main loop.
*
* @ingroup Efl_Loop
*/
Revert "fix warnings about redefinting EWAPI etc. due to windows EAPI changes" This reverts commit e2d6691d524e15b0b0673d121e81c0544271617b. This reverts commit c02b796fdb0960411b24576f654a03f0e765a842. This reverts commit 6c969f6b7d59e64e8bdf09a5e535de9561d77535. This reverts commit 74204bccd724fe9dee428056d4710f37bbc2cffb. This reverts commit 1304d9571775ef740ac6b8978ea4a2025a52c99a. This reverts commit 7c85be9674eaa0362b88f01c61107aa6e7c383a2. revert the EAPI changes that break cxx bindings build. sorry :( more fixes needed than i thought
2021-05-26 07:44:41 -07:00
EAPI void efl_exit(int exit_code);
elementary, ecore: move efl_exit helper to Ecore.
2017-10-27 16:37:58 -07:00
Revert "fix warnings about redefinting EWAPI etc. due to windows EAPI changes" This reverts commit e2d6691d524e15b0b0673d121e81c0544271617b. This reverts commit c02b796fdb0960411b24576f654a03f0e765a842. This reverts commit 6c969f6b7d59e64e8bdf09a5e535de9561d77535. This reverts commit 74204bccd724fe9dee428056d4710f37bbc2cffb. This reverts commit 1304d9571775ef740ac6b8978ea4a2025a52c99a. This reverts commit 7c85be9674eaa0362b88f01c61107aa6e7c383a2. revert the EAPI changes that break cxx bindings build. sorry :( more fixes needed than i thought
2021-05-26 07:44:41 -07:00
EAPI int efl_loop_exit_code_process(Eina_Value *value);
ecore: add infrastructure to handle an Eina_Value as an exit code.
2017-10-27 15:34:50 -07:00
ecore: rename Efl.Loop_User to Efl.Loop.Consumer.
2017-12-13 14:49:57 -08:00
#include "efl_loop_consumer.eo.h"
ecore: add an efl.loop_user class.
2016-05-05 16:18:18 -07:00
ecore: add some documentation for efl_loop_future_scheduler_get.
2018-01-03 11:37:38 -08:00
/**
* @brief Get the future scheduler for the current loop.
*
doxygen docs: Fix all invalid @param names There were quite a few of these...
2020-04-20 03:22:44 -07:00
* @param[in] obj An object which is either a loop or a loop consumer
ecore: add some documentation for efl_loop_future_scheduler_get.
2018-01-03 11:37:38 -08:00
* @return The current loop's future scheduler.
*/
Revert "fix warnings about redefinting EWAPI etc. due to windows EAPI changes" This reverts commit e2d6691d524e15b0b0673d121e81c0544271617b. This reverts commit c02b796fdb0960411b24576f654a03f0e765a842. This reverts commit 6c969f6b7d59e64e8bdf09a5e535de9561d77535. This reverts commit 74204bccd724fe9dee428056d4710f37bbc2cffb. This reverts commit 1304d9571775ef740ac6b8978ea4a2025a52c99a. This reverts commit 7c85be9674eaa0362b88f01c61107aa6e7c383a2. revert the EAPI changes that break cxx bindings build. sorry :( more fixes needed than i thought
2021-05-26 07:44:41 -07:00
EAPI Eina_Future_Scheduler *efl_loop_future_scheduler_get(const Eo *obj);
ecore: make efl_loop_future_scheduler_get shouldn't be exposed in the object function. Function declared in a .eo are something that we want to allow people to inherit from or use in a binding. I can't think of a situation where that would be the case for this function and it solves at the same time problem of needing a shared interface for both loop and loop_user.
2017-09-18 13:33:34 -07:00
ecore: add Efl.Loop.Fd. 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.
2016-05-06 15:33:36 -07:00
#include "efl_loop_fd.eo.h"
ecore - begin moving data into the efl loop data in the object we really should have data inside the loop object, so begin moving it one small thing at a time. this is the basics that will allow multiple efl loops. make an eo efl object and class for fd handlers that is efl loop bound make fd handlers really bound to their parent loop and not global as well as have a nice class/obj. create an message queue per loop and put legacy ecore events on top of it... and a lot more. this is not 100% done, but it's a lot of the core and groundwork. various ecore_timer_add(), ecore_diler_add() etc. need changes. The following still need doing: ecore_timer (internal usage for sure) ecore_idler (internal usage for sure) ecore_idle_enterer ecore_idle_exiter ecore_pollers? (is the new efl loop stuff ok?) ecore_exe (fork/spawn from any thread and track exe from that thread?) ecore_signal code ecore_throttle (should we have a single global too? we have per loop) ecore_app ? (should every loop be given its own argv/argc?) Lots of internal ecore code uses/calls these legacy calls and we should have efl loop replacements and/or use the ones we have The following will bedifferently designed for loop to loop control/messaging/ipc: ecore_thread ecore_pipe
2017-11-08 22:59:04 -08:00
#include "efl_loop_handler.eo.h"
ecore: add Efl.Loop.Fd. 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.
2016-05-06 15:33:36 -07:00
efl_interpolator: rename subclasses of Efl.Interpolator Subclasses of Efl.Interpolator are renamed intuitively from backward order to forward order.
2018-11-23 04:26:00 -08:00
#include "efl_linear_interpolator.eo.h"
#include "efl_accelerate_interpolator.eo.h"
#include "efl_decelerate_interpolator.eo.h"
#include "efl_sinusoidal_interpolator.eo.h"
#include "efl_divisor_interpolator.eo.h"
#include "efl_bounce_interpolator.eo.h"
#include "efl_spring_interpolator.eo.h"
#include "efl_cubic_bezier_interpolator.eo.h"
ecore: Add Efl.Interpolator class Efl.Interpolator class is to interpolate a value. Efl.Interpolator class has the following interpolation function classes as its subclasses. Efl.Interpolator.Linear Efl.Interpolator.Accelerate Efl.Interpolator.Decelerate Efl.Interpolator.Sinusoidal Efl.Interpolator.Divisor Efl.Interpolator.Bounce Efl.Interpolator.Spring Efl.Interpolator.Cubic_Bezier
2017-09-12 01:49:40 -07:00
ecore: add Efl.Promise.
2016-06-30 16:51:06 -07:00
/* We ue the factory pattern here, so you shouldn't call eo_add directly. */
Revert "fix warnings about redefinting EWAPI etc. due to windows EAPI changes" This reverts commit e2d6691d524e15b0b0673d121e81c0544271617b. This reverts commit c02b796fdb0960411b24576f654a03f0e765a842. This reverts commit 6c969f6b7d59e64e8bdf09a5e535de9561d77535. This reverts commit 74204bccd724fe9dee428056d4710f37bbc2cffb. This reverts commit 1304d9571775ef740ac6b8978ea4a2025a52c99a. This reverts commit 7c85be9674eaa0362b88f01c61107aa6e7c383a2. revert the EAPI changes that break cxx bindings build. sorry :( more fixes needed than i thought
2021-05-26 07:44:41 -07:00
EAPI Eo *efl_main_loop_get(void);
Ecore mainloop: Add .eo implementation.
2014-06-16 06:24:45 -07:00
ecore: Split Ecore headers 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.
2013-04-03 07:46:59 -07:00
/**
* @}
*/
efl.io: introduce basic interfaces and classes. 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.
2016-08-13 00:50:29 -07:00
/**
doxygen docs: Fix API reference group to Ecore_Eo This patch fixs a wrong group name in Ecore_Eo API reference Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org> Differential Revision: https://phab.enlightenment.org/D11952
2020-06-08 21:56:30 -07:00
* @ingroup Ecore
doxygen docs: Proper usage of @ingroup and @addtogroup This patch brings in a lot of docs which were missing before. Unfortunately, this brings along their warnings so this ends up adding more warnings than it fixes. Still, a step in the right direction. @ingroup puts the current block into the specified group, but IT DOES NOT allow opening groups with @{. This was used in lots of places, resulting in misplaced or ignored documentation. @ingroup should be used only in individual docs. For groups we use @defgroup and @addtogroup. Also,this patch adds some small missing docs.
2020-04-14 07:11:04 -07:00
* @addtogroup Ecore_Fd_Io_Group
efl.io: introduce basic interfaces and classes. 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.
2016-08-13 00:50:29 -07:00
*
* @{
*/
#include "efl_io_closer_fd.eo.h"
#include "efl_io_positioner_fd.eo.h"
#include "efl_io_reader_fd.eo.h"
#include "efl_io_sizer_fd.eo.h"
#include "efl_io_writer_fd.eo.h"
#include "efl_io_stdin.eo.h"
#include "efl_io_stdout.eo.h"
#include "efl_io_stderr.eo.h"
#include "efl_io_file.eo.h"
#include "efl_io_copier.eo.h"
efl_io_buffered_stream: wraps an I/O object and make it easy to use. Since all other efl.io objects are low-level, the recommended approach is to use an efl.io.copier. However when dealing with in-memory, bi-directional comms like talking to a socket, we always end with 2 queues, 2 copiers and the annoying setup that is being replicated in ecore_ipc, efl_debug and so on. This class is the base to make it simpler. Other classes such as Efl.Net.Socket.Simple, Efl.Net.Dialer.Simple and Efl.Net.Server.Simple will use it to provide simpler code to users. I guess we can call EFL+EO Java now?
2016-11-24 19:27:33 -08:00
#include "efl_io_buffered_stream.eo.h"
efl.io: introduce basic interfaces and classes. 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.
2016-08-13 00:50:29 -07:00
efl: add efl_model and efl_ui_view classes Efl.Model.Container and Efl.Model.Item to efl/interfaces are used to create Efl.Model objects with predefined property values. This is useful to any situation where we want an Efl.Model with explicit defined property values. Efl.Ui.View and Efl.Ui.Factory are used to connect Efl.Models with Widgets, Elm.Layout and Efl.Ui.Image has changed to use news interfaces Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2017-01-31 12:17:58 -08:00
/**
* @}
*/
/**
doxygen docs: Fix API reference group to Ecore_Eo This patch fixs a wrong group name in Ecore_Eo API reference Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org> Differential Revision: https://phab.enlightenment.org/D11952
2020-06-08 21:56:30 -07:00
* @ingroup Ecore
doxygen docs: Proper usage of @ingroup and @addtogroup This patch brings in a lot of docs which were missing before. Unfortunately, this brings along their warnings so this ends up adding more warnings than it fixes. Still, a step in the right direction. @ingroup puts the current block into the specified group, but IT DOES NOT allow opening groups with @{. This was used in lots of places, resulting in misplaced or ignored documentation. @ingroup should be used only in individual docs. For groups we use @defgroup and @addtogroup. Also,this patch adds some small missing docs.
2020-04-14 07:11:04 -07:00
* @addtogroup Ecore_Model_Group
efl: add efl_model and efl_ui_view classes Efl.Model.Container and Efl.Model.Item to efl/interfaces are used to create Efl.Model objects with predefined property values. This is useful to any situation where we want an Efl.Model with explicit defined property values. Efl.Ui.View and Efl.Ui.Factory are used to connect Efl.Models with Widgets, Elm.Layout and Efl.Ui.Image has changed to use news interfaces Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2017-01-31 12:17:58 -08:00
*
* @{
*/
efl_model : rename all efl_model based classes. Summary: As the result of discussion in T7458, we need to rename all efl_model based classes with efl_XXX_Model sequence. I've run few vote for this, see V42, V43 few classes are totally renamed as our consideration of misnaming. | Efl.Model_Loop | Efl.Loop_Model | | Efl.Model_Item | Efl.Generic_Model | | Efl.Model_Container | Efl.Container_Model | | Efl.Model_Container_Item | Efl.Container_Model_Item | | Efl.Model_Composite | Efl.Composite_Model | | Efl.Model_Composite_Boolean | Efl.Boolean_Model | | Efl.Model_Composite_Boolean_Chlidren | Efl.Boolean_Model_Item | | Efl.Model_Composite_Selection | Efl.Select_Model | | Efl.Model_Composite_Selection_Chlidren | Efl.Select_Model_Item | | Efl.Model_View | Efl.View_Model | | Eio.Model | Efl.Io.Model | | Efl.Ui.Model_State | Efl.Ui.State_Model | | Efl.Ui.Model_Size | Efl.Ui.Size_Model | | Efl.Ui.Model_Exact | Efl.Ui.Exact_Model | | Efl.Ui.Model_Average | Efl.Ui.Average_Model | | Efl.Ui.Model_Homogeneous | Efl.Ui.Homogeneous_Model | I worried about Efl.Io.Model changes, cause it is widely used, but as I tested, there is no issue found yet. Eldbus.Model also may can changed Efl.Dbus.Model, but I cannot found any class who using Efl.Dbus namespace, so I left it future work. Test Plan: Run the Make Test, it works well except Efl test about selection. there are class inheritance problem exist in select_model, I reported it and will fix it in another patch. Reviewers: cedric, felipealmeida, woohyun, Hermet Reviewed By: cedric Subscribers: lauromoura Tags: #efl, #do_not_merge Differential Revision: https://phab.enlightenment.org/D7533
2019-01-30 20:35:34 -08:00
#include "efl_loop_model.eo.h"
#include "efl_generic_model.eo.h"
#include "efl_container_model.eo.h"
#include "efl_composite_model.eo.h"
#include "efl_boolean_model.eo.h"
ecore: add Efl.Filter_Model This model provide facility to filter the content of composited model. Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com> Differential Revision: https://phab.enlightenment.org/D8797
2019-04-03 17:25:06 -07:00
#include "efl_filter_model.eo.h"
efl: add efl_model and efl_ui_view classes Efl.Model.Container and Efl.Model.Item to efl/interfaces are used to create Efl.Model objects with predefined property values. This is useful to any situation where we want an Efl.Model with explicit defined property values. Efl.Ui.View and Efl.Ui.Factory are used to connect Efl.Models with Widgets, Elm.Layout and Efl.Ui.Image has changed to use news interfaces Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2017-01-31 12:17:58 -08:00
efl.io: introduce basic interfaces and classes. 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.
2016-08-13 00:50:29 -07:00
/**
* @}
*/
ecore: Split Ecore headers 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.
2013-04-03 07:46:59 -07:00
#endif