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.
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.
style
The theme with double spinners is now a different style, so the user
can choice wich style he wants to use. It also removes the deprecated
flag from the elm_calendar_format_function_set() function.
SVN revision: 83095
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
Subject: [E-devel] [patch][elementary] calendar - add access feature,
access - add _elm_access_edje_object_part_object_unregister();
the attachment has accessibility feature which is for the
elm_calendar. and
moreover..
it would be better to keep one more api for the access which name is
_elm_access_edje_object_part_object_unregister();
in the case of calendar item, its text part could be set with empty
value
in run time(dynamically), even though it had a value (1~31) previously.
so if there is an empty field(item), then previously registered item
should
be unregistered. the api would be useful not only this case but also
others.
then, please review the patch and give feedback. thanks.
SVN revision: 76502
NOTE: This improve calendar performance quite a lot, but a better improvement
would be to populate the object when we really need it. I don't know how to
do that in current Elementary source code. Reason for another expected massive
improvement is that every time you set a property on an Elm_Calendar trigger
a populate and that one is costly (Around 6 populates call per Elm_Calendar in
our code example, meaning doing it could give us a 6 times boost...).
SVN revision: 74553
Daniel Juyung Seo
Cedric Bail
Daniel Zaoui
Daniel Juyung Seo
Tom Hacohen
Gustavo Lima Chaves
Bruno Dilly
Flavio Vinicius Alvares Ceolin
Shinwoo Kim
Yakov Goldberg
Michael BOUCHAUD
Cedric BAIL
Carsten Haitzler
Jihoon Kim
Jiyoun Park
Sanjeev BA
Sanjeev BA
Mike McCormack
Rajeev Ranjan