Summary:
Not everyone has a system or libraries that need to conform with
Freedesktop standards, making efreet not necessary on them.
This patch solves this by making efreet an optional library.
Test Plan:
`meson test -C build` + run edje, evas and elementary examples to
see if nothing got weird.
Ref T8814
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8814
Differential Revision: https://phab.enlightenment.org/D12151
This commit is based on 748e89e703 with a small change to compile in
Linux.
Original changes:
- ethumb(_client) depend on `ethumb` option
- Remove ethumb(_client) from ignored subprojects
- Remove ethumb_client from default elementary dependencies
Additional changes:
- Surround `_elm_unneed_ethumb();` call in
`src/lib/elementary/elm_main.c` with `#ifdef HAVE_ETHUMB`.
Co-authored-by: Felipe Magno de Almeida <felipe@expertise.dev>
The implementation design respects the fact that Eina_Thread is an
uintptr_t. Thus we allocate the thread struct in the heap and return a
pointer to it.
As such, we store the created thread structure in the target thread
TLS slot. For threads that were not created through eina API, in
eina_thread_self we allocate a new structure, push it to the TLS slot
and mark it to be freed on thread exit.
Reviewers: jptiz, walac, vtorri, woohyun, lucas
Reviewed By: jptiz, cedric
Subscribers: raster, cedric, #reviewers, #committers, lucas
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12037
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>
Patch 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
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Patch 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
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Patch 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
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
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>
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: jptiz, lucas, vtorri, woohyun
Reviewed By: jptiz, lucas, vtorri
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12203
Summary:
Eolian generator must have a parameter so it can generate the correct
symbol export/import macro for the API generated.
This makes it possible to define the symbols as being local to a
single DSO without the need to guard the generated headers or
generated source files with #define and #undef preprocessor
statements.
= 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: q66, vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12197
Summary:
Patch 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
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Reviewers: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
this will prevent textnodes content with <ps> or <br> without format node
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12145
Summary:
The style padding was included in native width(not in native height)
and formatted height(not in formatted width).
This is so weired. In addition, there is no enough document about
the relation between formatted size, native size and the style padding.
This issue is caused by a confusing code which is about how to handle
the style padding on item's width and height.("x_adjustment"!)
When Evas calculates "c->wmax" in line finalization stage, it explicitly subtract
style padding from line width. So, I assumed the formatted size has not to include
style padding. It is same for the native size.
The style padding will not be included in formatted size and native size by this commit.
@fix
Test Plan:
A test case is included in this commit.
Evas_Object *tb = evas_object_textblock_add(evas);
newst = evas_textblock_style_new();
evas_textblock_style_set(newst, "DEFAULT='font=Sans font_size=50 color=#000 text_class=entry'");
evas_object_textblock_style_set(tb, newst);
evas_object_textblock_text_markup_set(tb, "<style=far_soft_shadow>Test</>");
evas_object_textblock_style_insets_get(tb, &l, &r, &t, &b);
fail_if((l != 0) || (r != 4) || (t != 0) || (b != 4));
/* Size with style padding */
evas_object_textblock_size_formatted_get(tb, &w, &h);
evas_object_textblock_size_native_get(tb, &nw, &nh);
/* It is non-sense if the following condition is true. */
fail_if((w + l + r == nw) && (h == nh + t + b));
Reviewers: raster, ali.alzyod, woohyun, bowonryu
Reviewed By: ali.alzyod
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12110
Summary:
if we have rainbow flag emoji (🏳️‍🌈)
we can use mouse/keyboard to move cursor inside it because we break it into two clusters, we break on 1F308,
This is wrong as we should treat emoji as a single cluster (based on rules mentioned in Unicode segmentation standard “Do not break within emoji modifier sequences or emoji ZWJ sequences” (https://unicode.org/reports/tr29/#GB11 )).
this issue happens because we don’t give 1F308 its correct grapheme break property value, I think this is a bug in the unibreak library as this Unicode 1F308 should have word break class value equals to Glue_After_ZWJ (based on https://www.unicode.org/reports/tr29/tr29-31.html#Glue_After_Zwj_WB and http://unicode.org/Public/emoji/5.0/emoji-zwj-sequences.txt) which will not make it break and we will get a single cluster.
I noticed that the current unibreak lib used in EFL seems to implement Unicode 9 (latest is Unicode 13) which uses obsolete and unused grapheme break property, such as E_Modifier & Glue_After_ZWJ, so if a new emoji introduced (rainbow flag was introduced after Unicode 9) and based on Unicode 9 it should use property E_Modifier or Glue_After_ZWJ we will have issue with it.
So I have updated unibreak lib using latest released version of unibreak (4.2) which implement Unicode 12.
I needed to remove **BREAK_AFTER(i)** to pass the tests in D1140 as spaces do not break on latest update (also related to T995).
{F3868712}
this should fix T8665 & T8688
Reviewers: ali.alzyod, woohyun, bowonryu, zmike, segfaultxavi, bu5hm4n
Reviewed By: ali.alzyod
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8665
Differential Revision: https://phab.enlightenment.org/D11743
Although the [remove manpage](https://linux.die.net/man/3/remove) states that `remove(...)` deletes
either a file or a directory, this is not true in Windows as it can be seen in
[MSDN docs for
remove](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/remove-wremove?view=vs-2019):
> **(Function description)**
>
> Delete a file.
>
> **Return Value**
>
> Each of these functions returns 0 if the file is successfully deleted.
> Otherwise, **it returns -1 and sets errno either to EACCES to indicate that the
> path** specifies a read-only file, //**specifies a directory**//, or the file
> is open, or to ENOENT to indicate that the filename or path was not found.
This implementation detail caused the Eina test to fail and not removing the
temporary directory.
This patch changes the use of `remove` to the directory-specific `rmdir`, which
is guaranteed to remove the directory. Additionally, it also deletes the
Eina_TmpStr that holds the temporary directory path.
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12115
At least on Windows (didn't have the time to test on Linux yet),
running tests, even if they passed, there would be an Eina error on logs
pointing that a temporary file wasn't closed:
```
ERR:eina_file ../src/lib/eina/eina_file_common.c:1137 eina_file_shutdown() File [C:/Users/joao_/AppData/Local/Temp/aaaa_file_test_EBpVea] still open 1 times !
```
In the end, it was the `eina_file_test_unlink` that would create a temporary
file but never close it, being caught only by `eina_shutdown()`.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Differential Revision: https://phab.enlightenment.org/D12062
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12108
Summary: Resolve rendering e vowel (0x1031) with Myanmar(Burmese) with zero width non joiner (0x200C)
Test Plan: ninja test
Reviewers: woohyun, bowonryu
Reviewed By: bowonryu
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12102
Summary:
If shadow format changed using style_apply , the event EFL_CANVAS_TEXTBLOCK_EVENT_CHANGED will not be fired.
also added tests for it.
Reviewers: ali.alzyod, woohyun
Reviewed By: ali.alzyod
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11078
if this is set to 0 the next iteration in the upper frame event would
decrement the 0 again leading to a overflow making the iteration and
callback array overflow.
Long story short: set ifx to 1 to prevent overflow, test added.
fixes T8787
Differential Revision: https://phab.enlightenment.org/D12101
Summary:
setting color inside the constructor call will be override in theme apply because it happen later.
txt = efl_add(EFL_UI_TEXTBOX_CLASS, win,
efl_text_color_set(efl_added, 0, 255, 0, 255));
Now we will preserve user choice, to not change it during theme apply.
Test Plan: ninja test
Reviewers: woohyun, bu5hm4n, zmike, segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11942
Summary:
**key** value comes from keyboard down callbacks are common, regardless of language/layout but **keyname** is dependent on layout(in X11, in Wayland Can not be produced).
This common fix for both.
For example if keyboard layout in arabic then:
Ctrl+A will not work (in X11)
This one enhances D11606
Reviewers: woohyun, bu5hm4n, zmike
Reviewed By: woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11695
return the same variable set with gfx_filter_set.
added test for it.
Reviewed-by: Ali Alzyod <ali198724@gmail.com>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12071
there are tests that init & shutdown efl_object in the same test, which
is since to switch to const _CLASS_GET dangerously wrong.
I checked for more cases but only found cases where no _CLASS_GET
macros where used.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12069
please note, not the return type, but the function.
When appending __attribute__((const)) to a function, the compiler is
told that its enough to call this function once in a function.
This is quite often happening when we are efl_data_scope_get and
efl_super in a function that is different from a implemented function.
The compiler now starts to remove the calls that aggressivly that we
need to ensure that these calls are not removed, which means, the static
function calls, and the eo init are now checking the return value of
these functions, to ensure that they are called.
Please note that you now have to be carefull when your app calls
eo_shutdown, if it does so, you *must* call it at the end of a function,
or never call class_get after that anymore.
Overall this improves elm test runs 0.1s which is fair i guess, the main
thing that is faster is textrendering, where is also the point where
this is the most beneficial.
Please note, this replaces 42 occurences of double _class_get() ... THAT
is a sign!
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D12057
```
> c:\
> cd /windows
```
Are valid paths. Paths starting with '\' or '/' should be considered
absolute paths.
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D12022
On windows, we try to open the "cmd.exe" file, but without the full path
the test fails unless it runs from the system directory.
We now use the full path to test the eina_file_open function.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D12021
clang-cl doesn't support the syntax of dynamic stack allocated arrays.
ref: windows-native-port
Co-authored-by: Lucas <Coquinho@users.noreply.github.com>
Reviewed-by: Felipe Magno de Almeida <felipe@expertisesolutions.com.br>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11970
errno only holds a valid value if the function returns an error.
ref: windows-native-port
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11971
Summary:
when we set font source, for example with efl_text_font_source_set, the font source will not be updated in the textblock.
this is have same results that has been done in D9548
Test Plan:
#define EFL_EO_API_SUPPORT 1
#define EFL_BETA_API_SUPPORT 1
#include <Efl_Ui.h>
static void
_gui_quit_cb(void *data EINA_UNUSED, const Efl_Event *event EINA_UNUSED)
{
efl_exit(0);
}
static Eo *
_create_label(Eo *win, Eo *bx)
{
Eo *en;
en = efl_add(EFL_UI_TEXTBOX_CLASS, win);
printf("Added Efl.Ui.Text object\n");
efl_text_interactive_editable_set(en, EINA_FALSE);
efl_pack(bx, en);
return en;
}
static void
_gui_setup()
{
char buf[512], f_buf[512];
Eo *win, *bx;
win = efl_add(EFL_UI_WIN_CLASS, efl_main_loop_get(),
efl_ui_win_type_set(efl_added, EFL_UI_WIN_TYPE_BASIC),
efl_text_set(efl_added, "Hello World"),
efl_ui_win_autodel_set(efl_added, EINA_TRUE));
// when the user clicks "close" on a window there is a request to delete
efl_event_callback_add(win, EFL_UI_WIN_EVENT_DELETE_REQUEST, _gui_quit_cb, NULL);
bx = efl_add(EFL_UI_BOX_CLASS, win,
efl_content_set(win, efl_added),
efl_gfx_hint_size_min_set(efl_added, EINA_SIZE2D(360, 240)));
snprintf(buf, sizeof(buf), "./TestFontSource.eet");
Eo *en = _create_label(win, bx);
efl_text_set(en, "Hello, This Text Use The Font : Does_Not_Exists_Font_1 : Source + Font Name");
efl_text_font_source_set(en, buf);
efl_text_font_family_set(en, "Does_Not_Exists_Font_1");
efl_text_font_size_set(en, 35);
en = _create_label(win, bx);
efl_text_set(en, "Hello, This Text Use The Font : Does_Not_Exists_Font_1 : Font Name");
efl_text_font_family_set(en, "Does_Not_Exists_Font_1");
efl_text_font_size_set(en, 35);
en = _create_label(win, bx);
efl_text_set(en, "Hello, This Text Use The Font : Does_Not_Exists_Font_2 : Source + Font Name");
efl_text_font_source_set(en, buf);
efl_text_font_family_set(en, "Does_Not_Exists_Font_2");
efl_text_font_size_set(en, 35);
en = _create_label(win, bx);
efl_text_set(en, "Hello, This Text Use The Font : Does_Not_Exists_Font_2 : Font Name");
efl_text_font_family_set(en, "Does_Not_Exists_Font_2");
efl_text_font_size_set(en, 35);
}
EAPI_MAIN void
efl_main(void *data EINA_UNUSED, const Efl_Event *ev EINA_UNUSED)
{
_gui_setup();
}
EFL_MAIN()
Reviewers: ali.alzyod, woohyun, bowonryu, cedric
Reviewed By: ali.alzyod
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11757
Summary: when eina_strbuf_replace is used by read_only buffer, this will cause segfault (access invalid memory)
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8757
Differential Revision: https://phab.enlightenment.org/D11989