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.
If we want to share a gl context (we do) between multiple instances of
gl_drm, we need to make sure they all use the same gbm_device.
This resolves a blocker for multi-output on the gl_drm backend.
commit 0cf806005e correctly fixed a
leaked buffer. However, other code was already accounting for the
leaked reference to the buffer manager, so an extra deref happened
and broke the universe - but only on hardware that no developer
has access to for testing.
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
If group inherits after setting "inherit_script: 1;", inherit_script
is overwritten by the value of parent group. However, inherit_script
indicates user wants to inherit script in this context, it should not
be initialized as false.
Multi-head is hitting corner cases where there are lots of locked buffers
and it looks like right now 5 is the magic number that makes the problem
go away.
Make it possible to set 5 or more (via env var) for testing, make a macro
for MAX_BUFFERS instead of just a number.
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.
Small patch to destroy our test buffer before we exit the
_ecore_wl2_buffer_test function so that we do not leak here.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we are returning the evdev above, this block is unreachable so
remove it.
Fixes Coverity CID1382857
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If checked, it will list only the EO test cases.
Also add some stupid icons, and try to make the test case names more
uniform.
Test cases marked as EO are not necessarily 100% EO code, but it would
be good to make them so.
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
i forgot about that and this leads to a segfault in enlightenment, the
object then segfaults when the parent manager emits a event and then the
code tries to access the private data of a dead object.
As Cedric told me, eldbus_suite now fails on this line, where somehow
the properties array contains 2 elements, instead of 0 as expected. It
seems that the change is not related to EFL, but a new package on our
systems.
With d-feet (a dbus inspection tool), I can see two properties under:
org.freedesktop.DBus
/org/freedesktop/DBus or /
org.freedesktop.DBus
Properties
Features
Interfaces
Has anyone a better clue what's happening?
Amitesh Singh
Shilpa Singh
Derek Foreman
Marcel Hollerbach
Mike Blumenkrantz
Jeeyong Um
Pawel Aksiutowicz
Bryce Harrington
Chris Michael
Daniel Kolesa
Jean-Philippe Andre