Now that we're dependent on create_immed there's no possibility of falling
back to non dmabuf allocation.
The only failing case we really need to handle is failing the first
allocation, which is currently broken and I'll be adding an advance test
for it shortly.
wl_shm and dmabuf only really need to differ in how they allocate a buffer,
but right now we've got them in separate files. This dramatically
reduces the complexity of the wl_shm code and shares much more
implementation with the dmabuf code.
This throws away at least one "optimization" wl_shm used - over-allocating
buffers so that window resizing doesn't always require a new buffer
allocation. If people feel that window resizing has become too slow now
this can be added to the dmabuf code to the benefit of both allocators.
Disabling dmabuf by env var still uses the old wl_shm implementation for
now, but soon that code will be removed entirely and the env var disable
will use this path.
as decided by unanimous vote, the community does not want builds to pause or
stop when various features are disabled. warnings for disabling features have
been left intact
ref V30
@feature
this is needed for devices that no longer produce aspi events for
these. otherwise good luck getting any event on lid open/close or on
pressing the power button. this also stops hiding switch events from
libinput and now you can get switch events to find lid or tablet mode
switching changes.
@fix
Call provider_find on the loop (or basically any object) with the
color/text/size class interface instead, to find it. The main loop is
the main holder of those objects.
Note: This makes use of provider_find instead of direct access to the
variable, in order to self-test the code. In theory release builds will
not do this and user directly the variable.
we cant go iterating the mainloop before the current point. if someone
set up handlers but hasnt configured the things those handles use yet
as they dont expect them to be used until the mainloop is started...
thenthings break. we cant change this assumption without breaking
things.
if proxy fails are too many then give up on queued lookups as they
likely will continue. i noticed a process continually spawning efl net
proxy helper because one queued lookup failed and could be looked up
so it kept trying again and again.
@fix
The fix is not complete. We need to make efl_part() work nicely in C++:
- Get the refs work properly (maybe without auto-del)
- Generate the parts from the EO file as methods on the object
Final form should be close to:
slider.indicator().format_string_set("%1.2f");
Where everything autocompletes nicely :)
Summary:
9d2dcd92 requires elocation to build.
cxx examples still broken due to elm cleanup
Test Plan: make examples
Reviewers: jpeg, felipealmeida
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5426
Summary:
during elm_widget_theme_apply() state was set to off when state is on.
@fix
Test Plan: change locale/theme when a radio is on.
Reviewers: jpeg, cedric, woohyun
Differential Revision: https://phab.enlightenment.org/D5432
Build failed with LKI not found, as a symbol, but it's a macro.
Copy & pasted from evas_common_private.h
How can this work on one platform and not another? I don't get it...
the freeq can't allow things to access the content of the pointer
because the content canbe written over by canary handling qhen
submitted to the freeq. clear it inline then just submit the final
pointer to the freeq.
@fix
indicator_format_set/get & indicator_format_function_set are
now legacy APIs.
indicator format can be set by using generic Ui.Format function
e.g.
efl_ui_format_string_set(efl_part(sliderObj, "indicator"), "1.0%f");
elm_code_widget is causing a lot of trouble as it's relying on internal
access to elementary, without being built as part of elementary.so. Many
EAPI symbols are exported that shouldn't need to be, as they are only
internals of elm.