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
If you try to create a new widget, you must be sure that the parent
is really an evas object.
With the previous implementation it was possible to call an _add
function for an elementary widget with any non-null pointer as parent
eventually causing crashes (like with the elm_box).
SVN revision: 55521
Author: Helen Fornazier <helen.fornazier@profusion.mobi>
elm_slider now respond to the keyborad arrows depends on its position.
If it is in a horizontal mode, than its value will change by pressing
left and right, other wise it will respond by pressing up and down
elm_slideshow: go to next and previous with keyboard arrows
elm_spinner: respond to left and right keys in an animated way
SVN revision: 52816