There are elm_widget_theme/theme_set/theme_get functions.
In Eolian these functions will be described as "theme" method and
"theme" property. There is clash here.
So add suffix "_apply" to Eo API for "elm_widget_theme".
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
Older UI concept: when text in spinner's entry is inputted and text is
not committed yet and when inc/dec is clicked. do not commit text and
reset the value to older original value.
New UI concept:
When Text in spinner's entry is inputted and text is not committed yet
and when inc/dec buttons are clicked.
Commit the entry's text and inc/dec accordingly.
If entry' s text is already modified owing to min/max update, then do not inc/dec.
Signed-off by: Shilpa Singh <shilpa.singh@samsung.com>
There is a chance that spin timer is deleted in _value_set() by any chance.
So reset the spin timer and call _value_set after that.
Special thanks to Shilpa.
I think it's better to introduce elm_spinner_vertical_set() API to explicitly show the vertical mode but I will keep this new code for the backward compatibility.
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