there are situations where the entity is not ready yet when the initial
placing does happen. With this API you can tell the position manager
that the placing of the items can be reapplied at the entities are
availble now.
Differential Revision: https://phab.enlightenment.org/D9947
setting of these properties does not work, as they are not available in
legacy, but edje is still creating legacy objects.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10007
real part set was used to set the real part on the part, so the obj
pointer of Layout_Part_Data points to the correct evas object. With this
commit, this API is removed from the public .eo files, and is refactored
into the same API which is private.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9993
this api was missing, the pack method here is behaving in the same
manner as Efl.Ui.Table.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9992
Efl.Color and Efl.File cannot be done due to composition. Efl.Gfx.Image
can, so we can solve this via composition, this also resolves all the
other cases for Efl.Gfx.Image.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9991
EFL_UI_EVENT_ITEM_SELECTED / UNSELECTED is the wrong event here. We
should check of the selection changed event. ITEM_SELECTED is the legacy
event. this was not found based on the fact that we test for this event
to NOT be executed.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10011
we need to delete the callback here, otherwise the objects are deleted
later on, which:
- changes focus, which leads to
- callbacks executed with stacked addresses from a dead function
this fixes a testsuite failure on the release build.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D10020
This will fix Coverity issue.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9986
a while back we have moved event submission from custom lists to eo
events. We also merged together the freeze and thaw functions, however,
this brought up one bug. smart_callbacks and the likes (those that used
custom lists before) are not effected by the legacy freeze and thaw
functions. This means, we should declare these legacy wrapper objects
unfreezable in order to obtain this behaviour.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D10016
move more header includes around to fix building with Efl_Ui.h
ref T8228
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10022
this adds 4 more signal handling fds and loops over them for reading/writing
signal info in order to handle more signals when the buffer of one (or more)
pipes is full
also update the unit test to verify that we are receiving all the events without
dropping any and bump the number of signals to 2000 since we should now be able to
handle that many
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10027
this explodes after about 500 signals, so make it 1000 for a good test
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10026
if any efl-based process receives a bunch of signals in a short period of
time, it will deadlock in the signal handler. this is unavoidable given the
current signal handling architecture
by setting nonblock, we can at least avoid deadlocking even if it means we'll
be losing signal events
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10025
The condition here is that the composited interface does not
already appear in the inheritance tree of the given class. If
it does, don't add. If it doesn't, add it to the class that
specifies the composited block.
We need to keep in mind that the Manager and the Recognizers are not visible to the user.
The user only sees the events and the different Efl.Canvas.Gesture_* payloads.
Summary: This patch improves single line descriptions described on T7717
Test Plan: NA
Reviewers: segfaultxavi, woohyun, Hermet, cedric
Reviewed By: Hermet
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10002
If we check reference validation, the rest of other usage
should keep the reference check as well.
Remove it since gl prorgram must be valid always here
to shutdown the static analyzer reporting this suspicous logic.
legacy check widgets should not emit a "changed" event when using the api to
change the widget's state
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9852
verify that the "changed" callback is triggered as expected
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9832
legacy "check" and "toggle" widgets operate differently:
* check emits only the "toggle" event
* toggle emits "toggle", "on", "off"
legacy also must not emit events when the widget's state is changed
programmatically
to handle this effectively, check whether the event has been emitted for
each state when the signal is emitted from the theme, and track this
for subsequent uses to ensure that exactly one event is triggered
when it should be
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9831
this improves the usefulness of radio box by presenting it as a box widget
which has the additional feature of being able to manage radio widgets
also fix all the image cases in elm_test which relied on there being only
a single box in the window
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9998
these headers should be usable independently without having one secretly
pull in the other
fix T7667
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9981
this was somehow actually a legacy header which duplicated elm_calendar.h
...sort of
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9980
efl_ui_animation_view.h is the legacy header (but why?)
efl_ui_animation_view.eo.h is the unified header
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9979
.c files in src/lib/elementary should only include elm_priv.h to ensure
that all the include ordering is correct and that all necessary headers
are pulled in
.c files outside of src/lib/elementary should include either/both
Efl_Ui.h, Elementary.h as needed
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9978
this should include emotion, since that component is used internally,
and it should not explicitly include api headers which should be in
public headers
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9977
supposedly this header should be usable if someone wants to create an
elm widget, so ensure that it can be included without issues
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9976
this is a legacy header, it can't include any unified api types
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9974