Summary:
_elm_legacy_add goes back to EINA_FALSE after setting sd->legacy.
if constructor get called again after going back to EINA_FALSE,
sd->legacy should remain EINA_TRUE.
also, elm_legacy_add() should not be called non-elm_widget.
Test Plan:
Run elementary test->Efl.Ui.Text.Label.
Check legacy flag in _elm_theme_object_set() for efl_ui_win.
Check legacy flag for efl_ui_text after scrollable text is added.
Reviewers: jpeg, woohyun
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5529
Summary:
After the reorganization of elm eos, some sources include the .eo
headers directly instead of through Elementary.h. This causes problems
on windows as the declarations won't be decorated with the dllexport
attributes.
Reviewers: cedric, felipealmeida, jpeg, vtorri
Subscribers: jenkins
Tags: #windows, #efl
Differential Revision: https://phab.enlightenment.org/D5519
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
Added some guards to avoid redefinition of functions.
Partially fixes T5866, as there is still the question whether we should
test internal functions or not, as stated by jpeg in the comments.
Reviewers: vtorri, felipealmeida, jpeg, cedric
Reviewed By: cedric
Subscribers: jenkins, cedric
Maniphest Tasks: T5866
Differential Revision: https://phab.enlightenment.org/D5521
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Because of the way elm_code test case is written, by directly including
the C file, we end up with two symbols for the internal _elm_legacy_add
flag. This makes some test case fail (after applying a pending patch).
Solution found by Sungtaek Hong.
elm_code test case needs to be fixed. Don't include the C files
directly, testing static inlines should be done through a common .x or
something, but not by including the C file itself. This has led and will
lead to many issues.
Summary:
Information obtained by atspi client is name, role, description, state of an object.
reading_info_type_set/get APIs give control to application to decide on the information
that can be exposed.
Test Plan:
The reading info is added as an attribute of an accessible object, on query of
attribute, reading_info_type and corresponding character buffer should be given to ATSPI clients.
Reviewers: kimcinoo
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5524
Summary:
Send signal EFL_ACCESS_STATE_ANIMATED when dragging starts and stops to atspi clients and also set EFL_ACCESS_STATE_ANIMATED
when reorder mode is enabled.
Test Plan: When reorder happens atspi client should receive object:state-changed:animated signal.
Reviewers: kimcinoo, shilpasingh
Reviewed By: shilpasingh
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5515
Summary:
Add attribute append and attributes clear API, attributes of widget/widget_item helps in adding additional information
about the widget/widget item in the form of key-value pair.
Test Plan:
Query the attributes using atspi_accessible_get_attributes in atspi_client and an hash table consisting
of updates attributes should be returned.
Signed-Off By: Shilpa Singh <shilpa.singh@samsung.com>
Signed-Off By: Lukasz Wlazly <l.wlazly@partner.samsung.com>
Reviewers: kimcinoo, lukasz.stanislawski
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5510
with the previous commit we emit the legacy events for each interface
event, and thus this event is not needed.
However, in elm_entry this means that changing editable will _not_
reemit the focus event (where i am not that sure if that is correct or
not).
the widget itself never gets focus, the elements of the button are
getting them. MBE is basically just a box. The text input for the entry
is setted by elm_entry itself when it gets focus.
The legacy "focused" event is emitted somewhere seperatly.
this now keeps items arround even if a explicit other widget was
focused. This is usefull if we have a few logical items on the focus
stack and you remove them.
you think there is only one elm_parent behind the elementary property
parent? Oh no! Elm_Notify and Elm_Popup have theire own parent fields,
and those fields are not returned when calleing elm_widget_parent_get,
they are also not given to the elm_widget implementation of
elm_widget_top_get, so a call to elm_widget_top_get stalls at elm.notify
or elm.popup.
fix T6389
This function will destroy non-wayland engine data, so it should
make sure it's actually operating on a wayland window.
Originally the sd->wl.win test was sufficient, but now wl.win is
present on non-wl windows to facilitate cut and paste, so we need
to check more thoroughly.
The problem with the API is that it uses an array of ints, which is not
well defined in EO. We could set an array of pointers to int, but that
would be super awkward to use.
I believe the original API has been slightly over-engineered as it was
passing an array of available rotations when in reality only 4 rotations
could be supported (0, 90, 180, 270). It seems to me that the day
arbitrary rotation needs to be allowed, another API would be required
(maybe with a range, or a single bool flag to allow anything).
I have not modified the internal code, which still uses an array (as
ecore evas uses that).
Mote: ec464939d9 removed wm_rotation_supported_get(), as well as
the preferred rotation from EO, but they could easily be added back if
needed.
Note 2: I couldn't test as desktop E doesn't support WM rotations.
Ref T5322
When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
Jean-Philippe Andre
Sungtaek Hong
Pawel Aksiutowicz
Lauro Moura
Shilpa Singh
Andy Williams
Al Poole
Marcel Hollerbach
Amitesh Singh
WooHyun Jung
Prasoon Singh
Derek Foreman