2017-04-13 15:25:29 -07:00
|
|
|
/* This header is not to be installed and should only be used by EFL internals */
|
|
|
|
|
#ifndef _EVAS_INTERNAL_H
|
|
|
|
|
#define _EVAS_INTERNAL_H
|
|
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
#include <evas_api.h>
|
2017-04-13 15:25:29 -07:00
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-10-31 10:20:33 -07:00
|
|
|
#ifndef EFL_INTERNAL_UNSTABLE
|
|
|
|
|
# error This file can not be included outside EFL
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#include <Efl.h>
|
|
|
|
|
|
2019-10-31 10:20:52 -07:00
|
|
|
typedef struct _Evas_Object_Pointer_Data Evas_Object_Pointer_Data;
|
|
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK const Eina_List *efl_input_device_children_get(const Eo *obj);
|
2019-10-31 10:20:39 -07:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK void efl_input_device_evas_set(Eo *obj, Evas *e);
|
|
|
|
|
EVAS_API EVAS_API_WEAK Evas *efl_input_device_evas_get(const Eo *obj);
|
2019-10-31 10:20:39 -07:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK void efl_input_device_subclass_set(Eo *obj, Evas_Device_Subclass sub_clas);
|
|
|
|
|
EVAS_API EVAS_API_WEAK Evas_Device_Subclass efl_input_device_subclass_get(const Eo *obj);
|
2019-10-31 10:20:39 -07:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK void efl_input_device_grab_register(Eo *obj, Efl_Canvas_Object *grab, Evas_Object_Pointer_Data *pdata);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void efl_input_device_grab_unregister(Eo *obj, Efl_Canvas_Object *grab, Evas_Object_Pointer_Data *pdata);
|
2019-10-31 10:20:52 -07:00
|
|
|
|
2019-10-31 10:20:33 -07:00
|
|
|
typedef struct _Efl_Input_Pointer_Data Efl_Input_Pointer_Data;
|
|
|
|
|
typedef struct _Efl_Input_Key_Data Efl_Input_Key_Data;
|
|
|
|
|
typedef struct _Efl_Input_Hold_Data Efl_Input_Hold_Data;
|
|
|
|
|
typedef struct _Efl_Input_Focus_Data Efl_Input_Focus_Data;
|
|
|
|
|
|
|
|
|
|
#ifndef _EVAS_TYPES_EOT_H_
|
|
|
|
|
typedef struct _Evas_Modifier Evas_Modifier;
|
|
|
|
|
typedef struct _Evas_Lock Evas_Lock;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
struct _Efl_Input_Pointer_Data
|
|
|
|
|
{
|
|
|
|
|
Eo *eo;
|
|
|
|
|
unsigned int timestamp; /* FIXME: store as double? */
|
|
|
|
|
int button;
|
|
|
|
|
unsigned int pressed_buttons;
|
|
|
|
|
int touch_id; /* finger or tool ID */
|
|
|
|
|
double radius, radius_x, radius_y;
|
|
|
|
|
double pressure, distance, azimuth, tilt, twist;
|
|
|
|
|
double angle;
|
|
|
|
|
/* current, previous positions in window coordinates.
|
|
|
|
|
* raw can be either un-smoothed, un-predicted x,y or a tablet's raw input.
|
|
|
|
|
* norm is the normalized value in [0..1] for tablet input.
|
|
|
|
|
*/
|
|
|
|
|
Eina_Vector2 cur, prev, raw, norm;
|
|
|
|
|
struct {
|
|
|
|
|
int z;
|
|
|
|
|
Eina_Bool horizontal;
|
|
|
|
|
} wheel;
|
|
|
|
|
Efl_Gfx_Entity *source; /* could it be ecore? */
|
|
|
|
|
Efl_Input_Device *device;
|
|
|
|
|
Efl_Pointer_Action action;
|
|
|
|
|
Efl_Pointer_Flags button_flags;
|
|
|
|
|
Efl_Input_Flags event_flags;
|
|
|
|
|
void *data; /* evas data - whatever that is */
|
|
|
|
|
Eina_Bool window_pos; /* true if positions are window-relative
|
|
|
|
|
(see input vs. feed: this is "input") */
|
|
|
|
|
Evas_Modifier *modifiers;
|
|
|
|
|
Evas_Lock *locks;
|
|
|
|
|
void *legacy; /* DO NOT TOUCH THIS */
|
|
|
|
|
uint32_t value_flags;
|
|
|
|
|
Eina_Bool has_norm : 1; /* not in value_flags */
|
|
|
|
|
Eina_Bool has_raw : 1; /* not in value_flags */
|
|
|
|
|
Eina_Bool evas_done : 1; /* set by evas */
|
|
|
|
|
Eina_Bool fake : 1;
|
|
|
|
|
Eina_Bool win_fed : 1;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _Efl_Input_Key_Data
|
|
|
|
|
{
|
|
|
|
|
Eo *eo;
|
|
|
|
|
unsigned int timestamp; /* FIXME: store as double? */
|
|
|
|
|
|
|
|
|
|
Eina_Bool pressed; /* 1 = pressed/down, 0 = released/up */
|
|
|
|
|
Eina_Stringshare *keyname;
|
|
|
|
|
Eina_Stringshare *key;
|
|
|
|
|
Eina_Stringshare *string;
|
|
|
|
|
Eina_Stringshare *compose;
|
|
|
|
|
unsigned int keycode;
|
|
|
|
|
|
|
|
|
|
void *data;
|
|
|
|
|
Evas_Modifier *modifiers;
|
|
|
|
|
Evas_Lock *locks;
|
|
|
|
|
Efl_Input_Flags event_flags;
|
|
|
|
|
Efl_Input_Device *device;
|
|
|
|
|
void *legacy; /* DO NOT TOUCH THIS */
|
|
|
|
|
Eina_Bool evas_done : 1; /* set by evas */
|
|
|
|
|
Eina_Bool fake : 1;
|
|
|
|
|
Eina_Bool win_fed : 1;
|
|
|
|
|
Eina_Bool no_stringshare : 1;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _Efl_Input_Hold_Data
|
|
|
|
|
{
|
|
|
|
|
Eo *eo;
|
|
|
|
|
double timestamp;
|
|
|
|
|
Efl_Input_Flags event_flags;
|
|
|
|
|
Efl_Input_Device *device;
|
|
|
|
|
void *data;
|
|
|
|
|
void *legacy; /* DO NOT TOUCH THIS */
|
|
|
|
|
Eina_Bool hold : 1;
|
|
|
|
|
Eina_Bool evas_done : 1; /* set by evas */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _Efl_Input_Focus_Data
|
|
|
|
|
{
|
|
|
|
|
Eo *eo;
|
|
|
|
|
Efl_Input_Device *device; //The seat
|
|
|
|
|
Eo *object_wref; // wref on the focused object - Efl.Canvas.Object or Efl.Canvas.
|
|
|
|
|
double timestamp;
|
|
|
|
|
Efl_Input_Flags event_flags;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Internal helpers */
|
|
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
|
_efl_input_modifier_to_string(Efl_Input_Modifier mod)
|
|
|
|
|
{
|
|
|
|
|
switch (mod)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
case EFL_INPUT_MODIFIER_NONE: return NULL;
|
|
|
|
|
case EFL_INPUT_MODIFIER_ALT: return "Alt";
|
|
|
|
|
case EFL_INPUT_MODIFIER_CONTROL: return "Control";
|
|
|
|
|
case EFL_INPUT_MODIFIER_SHIFT: return "Shift";
|
|
|
|
|
case EFL_INPUT_MODIFIER_META: return "Meta";
|
|
|
|
|
case EFL_INPUT_MODIFIER_ALTGR: return "AltGr";
|
|
|
|
|
case EFL_INPUT_MODIFIER_HYPER: return "Hyper";
|
|
|
|
|
case EFL_INPUT_MODIFIER_SUPER: return "Super";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline const char *
|
|
|
|
|
_efl_input_lock_to_string(Efl_Input_Lock lock)
|
|
|
|
|
{
|
|
|
|
|
switch (lock)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
case EFL_INPUT_LOCK_NONE: return NULL;
|
|
|
|
|
case EFL_INPUT_LOCK_NUM: return "Num";
|
|
|
|
|
case EFL_INPUT_LOCK_CAPS: return "Caps";
|
|
|
|
|
case EFL_INPUT_LOCK_SCROLL: return "Scroll";
|
|
|
|
|
case EFL_INPUT_LOCK_SHIFT: return "Shift";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline Eina_Bool
|
|
|
|
|
_efl_input_value_has(const Efl_Input_Pointer_Data *pd, Efl_Input_Value key)
|
|
|
|
|
{
|
|
|
|
|
return (pd->value_flags & (1u << (int) key)) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
_efl_input_value_mark(Efl_Input_Pointer_Data *pd, Efl_Input_Value key)
|
|
|
|
|
{
|
|
|
|
|
pd->value_flags |= (1u << (int) key);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define _efl_input_value_mask(key) (1u << (int) key)
|
|
|
|
|
|
2017-04-13 15:25:29 -07:00
|
|
|
typedef struct _Efl_Canvas_Output Efl_Canvas_Output;
|
|
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API Efl_Canvas_Output *efl_canvas_output_add(Evas *canvas);
|
|
|
|
|
EVAS_API void efl_canvas_output_del(Efl_Canvas_Output *output);
|
|
|
|
|
EVAS_API void efl_canvas_output_view_set(Efl_Canvas_Output *output,
|
2017-04-13 15:25:29 -07:00
|
|
|
Evas_Coord x, Evas_Coord y, Evas_Coord w, Evas_Coord h);
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API void efl_canvas_output_view_get(Efl_Canvas_Output *output,
|
2017-04-13 15:25:29 -07:00
|
|
|
Evas_Coord *x, Evas_Coord *y, Evas_Coord *w, Evas_Coord *h);
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API Eina_Bool efl_canvas_output_engine_info_set(Efl_Canvas_Output *output,
|
2017-04-13 15:25:29 -07:00
|
|
|
Evas_Engine_Info *info);
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API Evas_Engine_Info *efl_canvas_output_engine_info_get(Efl_Canvas_Output *output);
|
|
|
|
|
EVAS_API Eina_Bool efl_canvas_output_lock(Efl_Canvas_Output *output);
|
|
|
|
|
EVAS_API Eina_Bool efl_canvas_output_unlock(Efl_Canvas_Output *output);
|
2017-04-13 15:25:29 -07:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API void evas_render_pending_objects_flush(Evas *eo_evas);
|
2017-12-19 03:37:25 -08:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API void efl_input_pointer_finalize(Efl_Input_Pointer *obj);
|
2017-05-18 01:37:26 -07:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API Eina_Iterator *efl_canvas_iterator_create(Eo *obj, Eina_Iterator *real_iterator, Eina_List *list);
|
2018-02-14 18:14:52 -08:00
|
|
|
|
2017-09-18 00:22:01 -07:00
|
|
|
static inline void
|
|
|
|
|
evas_object_size_hint_combined_min_get(const Eo *obj, int *w, int *h)
|
|
|
|
|
{
|
|
|
|
|
Eina_Size2D sz;
|
2019-02-21 09:19:45 -08:00
|
|
|
sz = efl_gfx_hint_size_combined_min_get(obj);
|
2017-09-18 00:22:01 -07:00
|
|
|
if (w) *w = sz.w;
|
|
|
|
|
if (h) *h = sz.h;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-12 08:14:49 -07:00
|
|
|
static inline void
|
|
|
|
|
evas_object_size_hint_combined_max_get(const Eo *obj, int *w, int *h)
|
|
|
|
|
{
|
|
|
|
|
Eina_Size2D sz;
|
|
|
|
|
sz = efl_gfx_hint_size_combined_max_get(obj);
|
|
|
|
|
if (w) *w = sz.w;
|
|
|
|
|
if (h) *h = sz.h;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-18 01:37:26 -07:00
|
|
|
/* Internal EO APIs */
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API Eo *evas_find(const Eo *obj);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void efl_canvas_object_legacy_ctor(Eo *obj);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void efl_canvas_object_type_set(Eo *obj, const char *type);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void efl_canvas_group_add(Eo *obj);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void efl_canvas_group_del(Eo *obj);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void efl_canvas_group_clipped_set(Eo *obj, Eina_Bool unclipped);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void evas_canvas_touch_point_list_nth_xy_get(Eo *obj, unsigned int n, double *x, double *y);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void evas_canvas_seat_focus_in(Eo *obj, Efl_Input_Device *seat);
|
|
|
|
|
EVAS_API EVAS_API_WEAK void evas_canvas_seat_focus_out(Eo *obj, Efl_Input_Device *seat);
|
|
|
|
|
EVAS_API EVAS_API_WEAK Eo* evas_canvas_seat_focus_get(const Eo *obj, Efl_Input_Device *seat);
|
|
|
|
|
|
|
|
|
|
EVAS_API EVAS_API_WEAK void *efl_input_legacy_info_get(const Eo *obj);
|
|
|
|
|
|
|
|
|
|
EVAS_API EVAS_API_WEAK Eo *efl_input_focus_instance_get(Efl_Object *owner, void **priv);
|
|
|
|
|
EVAS_API EVAS_API_WEAK Eo *efl_input_hold_instance_get(Efl_Object *owner, void **priv);
|
|
|
|
|
EVAS_API EVAS_API_WEAK Eo *efl_input_key_instance_get(Efl_Object *owner, void **priv);
|
|
|
|
|
EVAS_API EVAS_API_WEAK Eo *efl_input_pointer_instance_get(Efl_Object *owner, void **priv);
|
2019-02-23 05:22:11 -08:00
|
|
|
/**
|
|
|
|
|
* @brief If @c true the object belongs to the window border decorations.
|
|
|
|
|
*
|
|
|
|
|
* This will be @c false by default, and should be @c false for all objects
|
|
|
|
|
* created by the application, unless swallowed in some very specific parts of
|
|
|
|
|
* the window.
|
|
|
|
|
*
|
|
|
|
|
* It is very unlikely that an application needs to call this manually, as the
|
|
|
|
|
* window will handle this feature automatically.
|
|
|
|
|
*
|
|
|
|
|
* @param[in] obj The object.
|
|
|
|
|
* @param[in] is_frame @c true if the object is a frame, @c false otherwise
|
|
|
|
|
*
|
|
|
|
|
* @since 1.2
|
|
|
|
|
*
|
|
|
|
|
* @ingroup Efl_Canvas_Object
|
|
|
|
|
*/
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK void efl_canvas_object_is_frame_object_set(Eo *obj, Eina_Bool is_frame);
|
2019-02-23 05:22:11 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @brief If @c true the object belongs to the window border decorations.
|
|
|
|
|
*
|
|
|
|
|
* This will be @c false by default, and should be @c false for all objects
|
|
|
|
|
* created by the application, unless swallowed in some very specific parts of
|
|
|
|
|
* the window.
|
|
|
|
|
*
|
|
|
|
|
* It is very unlikely that an application needs to call this manually, as the
|
|
|
|
|
* window will handle this feature automatically.
|
|
|
|
|
*
|
|
|
|
|
* @param[in] obj The object.
|
|
|
|
|
*
|
|
|
|
|
* @return @c true if the object is a frame, @c false otherwise
|
|
|
|
|
*
|
|
|
|
|
* @since 1.2
|
|
|
|
|
*
|
|
|
|
|
* @ingroup Efl_Canvas_Object
|
|
|
|
|
*/
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK Eina_Bool efl_canvas_object_is_frame_object_get(const Eo *obj);
|
2017-05-22 01:20:35 -07:00
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK extern const Efl_Event_Description _EVAS_CANVAS_EVENT_RENDER_FLUSH_PRE;
|
2017-05-18 01:46:36 -07:00
|
|
|
#define EVAS_CANVAS_EVENT_RENDER_FLUSH_PRE (&(_EVAS_CANVAS_EVENT_RENDER_FLUSH_PRE))
|
|
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK extern const Efl_Event_Description _EVAS_CANVAS_EVENT_RENDER_FLUSH_POST;
|
2017-05-18 01:46:36 -07:00
|
|
|
#define EVAS_CANVAS_EVENT_RENDER_FLUSH_POST (&(_EVAS_CANVAS_EVENT_RENDER_FLUSH_POST))
|
|
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK extern const Efl_Event_Description _EVAS_CANVAS_EVENT_AXIS_UPDATE;
|
2017-05-18 01:46:36 -07:00
|
|
|
#define EVAS_CANVAS_EVENT_AXIS_UPDATE (&(_EVAS_CANVAS_EVENT_AXIS_UPDATE))
|
|
|
|
|
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK extern const Efl_Event_Description _EVAS_CANVAS_EVENT_VIEWPORT_RESIZE;
|
2017-05-18 01:46:36 -07:00
|
|
|
#define EVAS_CANVAS_EVENT_VIEWPORT_RESIZE (&(_EVAS_CANVAS_EVENT_VIEWPORT_RESIZE))
|
2017-05-18 01:37:26 -07:00
|
|
|
|
2017-05-18 01:52:17 -07:00
|
|
|
#define EFL_CANVAS_GROUP_DEL_OPS(kls) EFL_OBJECT_OP_FUNC(efl_canvas_group_del, _##kls##_efl_canvas_group_group_del)
|
|
|
|
|
#define EFL_CANVAS_GROUP_ADD_OPS(kls) EFL_OBJECT_OP_FUNC(efl_canvas_group_add, _##kls##_efl_canvas_group_group_add)
|
|
|
|
|
#define EFL_CANVAS_GROUP_ADD_DEL_OPS(kls) EFL_CANVAS_GROUP_ADD_OPS(kls), EFL_CANVAS_GROUP_DEL_OPS(kls)
|
|
|
|
|
|
2018-01-16 03:31:15 -08:00
|
|
|
/* Efl.Animation.Player */
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API EVAS_API_WEAK extern const Efl_Event_Description _EFL_ANIMATION_PLAYER_EVENT_PRE_STARTED;
|
2018-01-16 03:31:15 -08:00
|
|
|
#define EFL_ANIMATION_PLAYER_EVENT_PRE_STARTED (&(_EFL_ANIMATION_PLAYER_EVENT_PRE_STARTED))
|
|
|
|
|
/* Efl.Animation.Player END */
|
2017-08-25 01:17:24 -07:00
|
|
|
|
elm_entry: handle cursor delete/backspace with clusters consist of one or multible glyphs
Summary:
Cluster consist of one glyph, expected to be removed on backspace or delete key.
Cluster consist of multible glyph, expectd to remove part of on backspace or delete key.
This is behaviour founded in Android. (our current way of handling similar to Qt)
**New Behaviour**
{F3750386}
**Old Behaviour**
{F3750387}
Test Plan:
Auto Testing is challenging because there are no easy way to emulate keyboard down on elm_entry
```
#include <Elementary.h>
EAPI_MAIN int
elm_main(int argc, char **argv)
{
Evas_Object *win,*box,*entry;
elm_policy_set(ELM_POLICY_QUIT, ELM_POLICY_QUIT_LAST_WINDOW_CLOSED);
win = elm_win_util_standard_add("", "");
elm_win_autodel_set(win, EINA_TRUE);
box = elm_box_add(win);
entry = elm_entry_add(box);
evas_object_size_hint_weight_set(box,EVAS_HINT_EXPAND,EVAS_HINT_EXPAND);
evas_object_size_hint_align_set(box,EVAS_HINT_FILL,EVAS_HINT_FILL);
elm_entry_entry_set(entry,"<font=NotoColorEmoji wrap=mixed >🇧🇬อั🇧🇬อั😀😀😀😀😀อั</font>");
evas_object_size_hint_weight_set(entry,EVAS_HINT_EXPAND,0.9);
evas_object_size_hint_align_set(entry,EVAS_HINT_FILL,EVAS_HINT_FILL);
evas_object_show(entry);
evas_object_show(box);
elm_box_pack_end(box,entry);
elm_win_resize_object_add(win,box);
evas_object_resize(win,320,480);
evas_object_size_hint_weight_set(entry,EVAS_HINT_EXPAND,0.1);
evas_object_size_hint_align_set(entry,EVAS_HINT_FILL,EVAS_HINT_FILL);
evas_object_show(win);
elm_run();
return 0;
}
ELM_MAIN()
```
Reviewers: tasn, woohyun, bowonryu
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9628
2019-09-04 22:52:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*TextBlock Internal function*/
|
|
|
|
|
/**
|
|
|
|
|
* Check if cursor is at cluster with one glyph (replace codepoints with new codepoint).
|
|
|
|
|
*
|
|
|
|
|
* @param cur the cursor.
|
|
|
|
|
* @param forward if Eina_True check cluster after cusror position, else before cursor position.
|
|
|
|
|
*/
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API Eina_Bool evas_textblock_cursor_at_cluster_as_single_glyph(Evas_Textblock_Cursor *cur,Eina_Bool forward);
|
elm_entry: handle cursor delete/backspace with clusters consist of one or multible glyphs
Summary:
Cluster consist of one glyph, expected to be removed on backspace or delete key.
Cluster consist of multible glyph, expectd to remove part of on backspace or delete key.
This is behaviour founded in Android. (our current way of handling similar to Qt)
**New Behaviour**
{F3750386}
**Old Behaviour**
{F3750387}
Test Plan:
Auto Testing is challenging because there are no easy way to emulate keyboard down on elm_entry
```
#include <Elementary.h>
EAPI_MAIN int
elm_main(int argc, char **argv)
{
Evas_Object *win,*box,*entry;
elm_policy_set(ELM_POLICY_QUIT, ELM_POLICY_QUIT_LAST_WINDOW_CLOSED);
win = elm_win_util_standard_add("", "");
elm_win_autodel_set(win, EINA_TRUE);
box = elm_box_add(win);
entry = elm_entry_add(box);
evas_object_size_hint_weight_set(box,EVAS_HINT_EXPAND,EVAS_HINT_EXPAND);
evas_object_size_hint_align_set(box,EVAS_HINT_FILL,EVAS_HINT_FILL);
elm_entry_entry_set(entry,"<font=NotoColorEmoji wrap=mixed >🇧🇬อั🇧🇬อั😀😀😀😀😀อั</font>");
evas_object_size_hint_weight_set(entry,EVAS_HINT_EXPAND,0.9);
evas_object_size_hint_align_set(entry,EVAS_HINT_FILL,EVAS_HINT_FILL);
evas_object_show(entry);
evas_object_show(box);
elm_box_pack_end(box,entry);
elm_win_resize_object_add(win,box);
evas_object_resize(win,320,480);
evas_object_size_hint_weight_set(entry,EVAS_HINT_EXPAND,0.1);
evas_object_size_hint_align_set(entry,EVAS_HINT_FILL,EVAS_HINT_FILL);
evas_object_show(win);
elm_run();
return 0;
}
ELM_MAIN()
```
Reviewers: tasn, woohyun, bowonryu
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9628
2019-09-04 22:52:51 -07:00
|
|
|
|
Efl.Text.Attribute_Factory
Summary:
Implementation of new Efl.Text.Attribute_Factory class which replace the annotation interface.
Currently, we have two public methods:
```
void efl_text_attribute_factory_attribute_insert(const Efl_Text_Cursor *start, const Efl_Text_Cursor *end, const char *format)
unsigned int efl_text_attribute_factory_attribute_clear(const Efl_Text_Cursor *start, const Efl_Text_Cursor *end);
```
Other methods will be internal methods, for the time being, we will redesign internal methods
Reviewers: woohyun, tasn, segfaultxavi, bu5hm4n, zmike
Subscribers: zmike, q66, cedric, segfaultxavi, bu5hm4n, a.srour, #committers, #reviewers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10646
2019-11-26 20:04:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*Attribute Factory Internal function*/
|
evas: Rename EAPI macro to EVAS_API in Evas library
Summary:
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>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
2020-12-15 18:02:20 -08:00
|
|
|
EVAS_API const char * efl_text_formatter_attribute_get(Efl_Text_Attribute_Handle *annotation);
|
|
|
|
|
EVAS_API Eina_Iterator * efl_text_formatter_range_attributes_get(const Efl_Text_Cursor_Object *start, const Efl_Text_Cursor_Object *end);
|
|
|
|
|
EVAS_API void efl_text_formatter_attribute_cursors_get(const Efl_Text_Attribute_Handle *handle, Efl_Text_Cursor_Object *start, Efl_Text_Cursor_Object *end);
|
|
|
|
|
EVAS_API void efl_text_formatter_remove(Efl_Text_Attribute_Handle *annotation);
|
|
|
|
|
EVAS_API Eina_Bool efl_text_formatter_attribute_is_item(Efl_Text_Attribute_Handle *annotation);
|
|
|
|
|
EVAS_API Eina_Bool efl_text_formatter_item_geometry_get(const Efl_Text_Attribute_Handle *annotation, int *x, int *y, int *w, int *h);
|
Efl.Text.Attribute_Factory
Summary:
Implementation of new Efl.Text.Attribute_Factory class which replace the annotation interface.
Currently, we have two public methods:
```
void efl_text_attribute_factory_attribute_insert(const Efl_Text_Cursor *start, const Efl_Text_Cursor *end, const char *format)
unsigned int efl_text_attribute_factory_attribute_clear(const Efl_Text_Cursor *start, const Efl_Text_Cursor *end);
```
Other methods will be internal methods, for the time being, we will redesign internal methods
Reviewers: woohyun, tasn, segfaultxavi, bu5hm4n, zmike
Subscribers: zmike, q66, cedric, segfaultxavi, bu5hm4n, a.srour, #committers, #reviewers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10646
2019-11-26 20:04:31 -08:00
|
|
|
|
2017-04-13 15:25:29 -07:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#endif
|
