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?
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
Pawel Aksiutowicz
Bryce Harrington
Derek Foreman
Chris Michael
Daniel Kolesa
Jean-Philippe Andre
Marcel Hollerbach
Lukasz Stanislawski
Cedric Bail
Andrii Kroitor