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?
elm_object_item_focus_set ensures that the list also gets focus, thus calling
that in _elm_list_elm_widget_on_focus_update would result in a infinite
call recursion, if setting the focus fails (for example when the object
is not visible yet, [see enlightenment for that]).
This fixes a freeze if you open lunchers config.
We no longer allocate 3 buffers at startup, we now allocate only as needed.
Trimming the queue will come later, as there are some situations where we
might need 3 buffers and later drop down to 2 (when on a hardware plane)
Most clients will only ever need 2 buffers, so this is a reasonable RAM
savings.
this leads in eo to the meaning that the manager.sub is giving
implementations to that interface, but leaving the ->func with NULL,
which leads on some maschines to the assumation that this is
pure_virtual, which means not composition objects will be queried, on
other maschines this will work, since there other inherits will
overwrite this entry and set ->src to NULL.
While i still dont understand why this works on some maschines and does
not on others, this is is now fixed.
_followup_previous_direction should only be called if there was a real
change to the redirect. In was happening that we have not changed the
focus but called _followup_previous_direction, which lead to weird focus
changes.
Conditions:
- style is "double_label"
- the is some content for items (i.e elm_label)
- elm_genlist_filter set was once called after genlist creation with
NULL data
- label_get callback uses elm_genlist_item_prev_get on its current item
- at least one item is added as a sub-item
- ~2 blocks of items are added afterwards
- items are added quickly while holding 'enter' on an elm_button
@fix
I had eldbus_suite and eldbus_cxx_suite fail quite often for some
strange reason: name already in use... yeah but by who??? Turns out both
test cases used the same name, and when ran in parallel (make -j10
check) this would often fail.
Summary:
Modified index item role to EFL_ACCESS_ROLE_RADIO_MENU_ITEM from EFL_ACCESS_ROLE_PUSH_BUTTON
as index item should maintain its current state.
Test Plan:
Query the role of index item from atspi client, ATSPI_ROLE_RADIO_MENU_ITEM role should
be returned.
Reviewers: kimcinoo
Reviewed By: kimcinoo
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5486
Summary:
The accessibility clients should not have a possibility
to dismiss popup in case when action area is set.
Reviewers: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5481
Summary: When Index item is selected, notify atspi clients.
Test Plan:
when atspi mode is enabled, item selection notification
should be received by atspi client
Reviewers: kimcinoo
Subscribers: cedric, govi, rajeshps, jpeg
Differential Revision: https://phab.enlightenment.org/D5485
Summary: Try to take access name from internal entry object or text button first.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5480
This thing is used by only 2 EO APIs that are marked as @beta. I wonder
if the @beta tag or the ptr() expression made it work for eolian,
because it simply wasn't defined in EO.
I'm renaming it just so that it's more consistent with the new names
used by atspi (and EO API in general).