Summary:
The use of elm_widget_type_get here is pretty harmfull, for the usecase
of inheriting a widget elm_widget_type_get is something else than
before. But the key binding should still work.
@fix T2891
Reviewers: tasn
Reviewed By: tasn
Maniphest Tasks: T2891
Differential Revision: https://phab.enlightenment.org/D3470
Summary:
Currently when user clicks on the checkbox, and when api state_check() called by
the developer we emit "elm,state,check,*" signal. To support state change animation when
user interacts with check box. There is no way to distinguish the action in EDC.
This "elm,activate,check,*" is a way which edc can make use to distinguish the stae change signal
by the user action or due to api call.
Reviewers: woohyun, raster, cedric, Hermet
Reviewed By: Hermet
Subscribers: id213sin
Differential Revision: https://phab.enlightenment.org/D2817
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Checkbox should support a third state "indeterminate" along with "Checked" and "Unchecked"
This third state is a state of checkbox which is shown when checkbox is neither Checked nor Unchecked.
- Added this new feature on the basis of a boolean variable's value.
- By default this boolean variable is disabled and checkbox will treat like old way.
- While adding this, I kept in mind, that applications which are already using checkbox, should not be affected, so I used 0=False=Unchecked, 1=True=Checked, and 2=Indeterminate
- Also added an example check_example_o2.c, which is using checkbox with both ways, using boolean, and using enum.
- Now also values can be set using boolean values, but it will give a type casting warning. As a boolean doen't support third state, so I used an enum int like.
- Added APIs to enable disable third state mode. elm_check_three_state_mode_set(check_obj, bool_val), and elm_check_three_state_mode_get(check_obj)
- Modified old APIs which were setting or getting states of checkbox.
- Added a state in theme of checkbox, with third state image.
Reviewers: seoz, raster, Sergeant_Whitespace, Hermet
Subscribers: Hermet, Sergeant_Whitespace, sachin.dev
Differential Revision: https://phab.enlightenment.org/D2249
Summary:
Change requested by TAsn. Previuosly AT-SPI headers were kept private
and included directly into elementary source code. From now on,
AT-SPI headers can be included from Elementary.h public header, however
will be marked as beta APIs.
Commit includes following changes:
* include all atspi headers into new elm_interfaces.h header.
* marking all at-spi interfaces methods/properties as @protected.
* wrap all common headers with EFL_BETA_API_SUPPORT.
* make some common APIs visible in lib, by adding EAPI attribute
(if someone decides to use beta APIs).
Test Plan: out-off tree build with gcc, g++
Reviewers: tasn
Reviewed By: tasn
Subscribers: seoz, q66, kuuko
Maniphest Tasks: T1721
Differential Revision: https://phab.enlightenment.org/D1528
Summary:
Main purpose of exposing widget actions and keyboard shortcuts
is to allow accessibility clients to implement alternative methods
of GUI navigation.
Reviewers: z.kosinski
Reviewed By: z.kosinski
Subscribers: seoz
Differential Revision: https://phab.enlightenment.org/D1227
we can prevent to handle the widget events from the widget infra,
if the object is disabled.
conceptually, disabled object should not be interacted to user input(key, mouse)
Summary:
apply key binding to 4 widgets
this revision is only for reviewing
I'll send 4 seperate patches after review is done.
Test Plan: None
Reviewers: Hermet, seoz, raster
Differential Revision: https://phab.enlightenment.org/D678
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.
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.
+ 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