I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
1. ELM_FREE_FUNC -> ELM_SAFE_FREE
2. There were a lot of suggestions and consideration in the mailing list.
ELM_SAFE_FREE will be used only when it checks the pointer, deletes it, and initializes it to NULL.
ex)
if (timer)
{
ecore_timer_del(timer);
timer = NULL;
}
=>
ELM_SAFE_FREE(timer, ecore_timer_del);
My first aim was to remove many human mistakes but it looks like people want more optimized code in a code level.
So this macro will be used only for reducing 5 lines of code into 1 line.
Otherwise, I will just call xxx_del() manually.
3. ELM_SAFE_FREE can be used for other del or free functions such as ecore_job_del, ecore_animator_del, eina_stringshare_del, free, ...
Apps like setting want to change gesture tap timeout value on runtime.
So I added below APIs.
elm_config_glayer_long_tap_start_timeout_set/get
elm_config_glayer_double_tap_timeout_set/get
As document mentioned, "changed" should be emitted when the color value is changed.
So, this patch emits "changed" signal when color value is really changed.
In addition, fixed some formatting issue of test_colorselector.
There are pros and cons but this
1. reduces human mistakes.
2. enhances readability.
3. enhances code quality.
4. removes future bug.
5. was adopted from enlightenment.
This is not all. I will work on enhancing elementary more and more.
When we call elm_entry_markup_filter_remove() with internally defined filter callbacks,
it doesn't work. So we need a one of pointer for saving the address of data.
10 Elm_Entry_Filter_Limit_Size lim;
11 lim.max_char_count = 20;
12 lim.max_byte_count = 0;
13 elm_entry_markup_filter_append(en, elm_entry_filter_limit_size,
&lim);
14
15 elm_entry_markup_filter_remove(en, elm_entry_filter_limit_size,
&lim);
16 lim.max_char_count = 50;
17 lim.max_byte_count = 0;
18 elm_entry_markup_filter_append(en, elm_entry_filter_limit_size,
&lim);
In this code, we expect to see the filter of entry will be renewed.
But elm_entry_markup_filter_remove() doesn't work.
Because, markup_filter does not hold the address of data when we use
the filter callback which is defined in elm_entry.c
_filter_new() in elm_entry.c
You can see that _filter_new allocates new pointer and names as lim2.
lim2 is saved in data of _Elm_Entry_Markup_Filter. So the address of
data doesn't equal to the input data.