I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
1. Do not need to print the same error message from all the widget codes.
2. Even though elm_widget_sub_object_add() can be used internally, there should be no error message at all.
Elm devs should fix it beforehand.
So it looks ok to print the error message in elm_widget_sub_object_add() to force elm devs to fix it.
3. Got additional code cleanups.
The size should remain the same after the first mouse move and then be
adjusted accordingly.
Fixes#1403.
Patch by: "Brian J. Lovin" <brian.j.lovin@intel.com>
Smart data is already initialized so we do not need to re-initialize them if the value equals to 0, NULL, or EINA_FALSE.
Sometimes re-initializing smart data explicitly is needed for readability. So there are left overs.
SVN revision: 82228
+ elm_access_object_register();
+ elm_access_object_unregister();
+ elm_access_text_set();
+ elm_access_text_get();
+ elm_access_cb_set();
These APIs are to use edje part, evas object as an accessible object.
and do not create access object, because access object would be created at run time.
This is different with internal API _elm_access_object_register();
SVN revision: 81659
It's weird, but looks like wrap mode of the spinner is broken at least
since the move of elm to trunk.
The current code:
if (sd->wrap)
{
while (new_val < sd->val_min)
new_val = sd->val_max + new_val + 1 - sd->val_min;
while (new_val > sd->val_max)
new_val = sd->val_min + new_val - sd->val_max - 1;
}
doesn't seems correct. Since even the documented example would fails:
* E.g.:
* @li min value = 10
* @li max value = 50
* @li step value = 20
* @li displayed value = 20
*
* When the user decrement value (using left or bottom arrow), it will
* displays @c 40, because max - (min - (displayed - step)) is
* @c 50 - (@c 10 - (@c 20 - @c 20)) = @c 40.
With the current code the value will be 41.
It also could lead to values above min, like happens on the first spinner test,
when you could go to -50.5 because new value will become:
250 + (-50.5) + 1 - (-50) in the first while() and later since these value
is bigger then 250, would go back to -50.5 ...
So, a reasonable algorithm would be
if (sd->wrap)
{
if (new_val < sd->val_min)
new_val = sd->val_max + new_val - sd->val_min;
else if (new_val > sd->val_max)
new_val = sd->val_min + new_val - sd->val_max;
}
But it doesn't works fine for cases like the months spinners test, when you
have min = 1, max = 12, step = 1 and each option should be displayed with
wrap. This algorithm would wraps from 1 to 11, so would skip December...
So, I think just going to the max value when min is reached is the better
choice.
if (sd->wrap)
{
if (new_val < sd->val_min)
new_val = sd->val_max;
else if (new_val > sd->val_max)
new_val = sd->val_min;
}
SVN revision: 77278
Daniel Juyung Seo
Shinwoo Kim
ChunEon Park
WooHyun Jung
Carsten Haitzler
Cedric Bail
Daniel Zaoui
Tom Hacohen
Daniel Juyung Seo
Gustavo Lima Chaves
Rafael Antognolli
Shinwoo Kim
Yakov Goldberg
Jihoon Kim
Michael BOUCHAUD
Bruno Dilly
Cedric BAIL