kimcinoo
/
efl
forked from enlightenment/efl
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
efl/src/lib/elementary/elm_naviframe_item_eo.h

100 lines
3.1 KiB
C
Raw Normal View History

elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
#ifndef _ELM_NAVIFRAME_ITEM_EO_H_
#define _ELM_NAVIFRAME_ITEM_EO_H_
#ifndef _ELM_NAVIFRAME_ITEM_EO_CLASS_TYPE
#define _ELM_NAVIFRAME_ITEM_EO_CLASS_TYPE
typedef Eo Elm_Naviframe_Item;
#endif
#ifndef _ELM_NAVIFRAME_ITEM_EO_TYPES
#define _ELM_NAVIFRAME_ITEM_EO_TYPES
#endif
/** Elementary naviframe item class
*
* @ingroup Elm_Naviframe_Item
*/
#define ELM_NAVIFRAME_ITEM_CLASS elm_naviframe_item_class_get()
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
2020-10-11 09:00:04 -07:00
ELM_API ELM_API_WEAK const Efl_Class *elm_naviframe_item_class_get(void) EINA_CONST;
elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
/**
* @brief Pop the top item and delete the items between the top and the above
* one on the given item.
*
* The items between the top and the given item will be deleted first, and then
* the top item will be popped at last.
*
* @warning The pop callback function set by elm_naviframe_item_pop_cb_set is
* not called for items between the top item and the destination item since
* those items are deleted without being popped.
* @param[in] obj The object.
*
* @ingroup Elm_Naviframe_Item
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
2020-10-11 09:00:04 -07:00
ELM_API ELM_API_WEAK void elm_obj_naviframe_item_pop_to(Eo *obj);
elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
/**
* @brief Get a value whether title area is enabled or not.
*
* @param[in] obj The object.
*
* @return If @c true, title area will be enabled, disabled otherwise
*
* @ingroup Elm_Naviframe_Item
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
2020-10-11 09:00:04 -07:00
ELM_API ELM_API_WEAK Eina_Bool elm_obj_naviframe_item_title_enabled_get(const Eo *obj);
elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
/**
* @brief Enable/Disable the title area with transition effect
*
* When the title area is disabled, then the controls would be hidden so as to
* expand the content area to full-size.
*
* @param[in] obj The object.
* @param[in] enable If @c true, title area will be enabled, disabled otherwise
* @param[in] transition If @c true, transition effect of the title will be
* visible, invisible otherwise
*
* @ingroup Elm_Naviframe_Item
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
2020-10-11 09:00:04 -07:00
ELM_API ELM_API_WEAK void elm_obj_naviframe_item_title_enabled_set(Eo *obj, Eina_Bool enable, Eina_Bool transition);
elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
/**
* @brief Promote an item already in the naviframe stack to the top of the
* stack.
*
* This will take the indicated item and promote it to the top of the stack as
* if it had been pushed there. The item must already be inside the naviframe
* stack to work.
* @param[in] obj The object.
*
* @ingroup Elm_Naviframe_Item
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
2020-10-11 09:00:04 -07:00
ELM_API ELM_API_WEAK void elm_obj_naviframe_item_promote(Eo *obj);
elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
/**
* @brief Set a function to be called when an item of the naviframe is going to
* be popped.
*
* @warning Don't set "clicked" callback to the prev button additionally if the
* function does an exact same logic with this @c func. When hardware back key
* is pressed then both callbacks will be called. Warning: The pop callback
* function is called only if the item is popped. Therefore, the pop callback
* function is not called if the item is deleted without being popped.
*
* @param[in] obj The object.
* @param[in] func The callback function.
* @param[in] data Data to be passed to func call.
*
* @since 1.8
*
* @ingroup Elm_Naviframe_Item
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = This patch is from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why LIBAPI is the only solution that works for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
2020-10-11 09:00:04 -07:00
ELM_API ELM_API_WEAK void elm_obj_naviframe_item_pop_cb_set(Eo *obj, Elm_Naviframe_Item_Pop_Cb func, void *data);
elm_naviframe*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8186
2019-03-05 14:00:37 -08:00
#endif