Summary:
It is not necessary to specify @brief since the first line will
automatically be used, but if it is used it should be only for the brief
description, not the detailed description.
Also reformat other docs in this file to follow convention for the brief
docs.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5101
Objects show should happen as early as possible during the render cycle,
as it affects smart objects calculation and everything else.
Thanks @JackDanielZ for the report!
Fixes T5880
Issue: If the item has weight and non-filled align, item is not resized.
This patch fixes this issue.
Test: elementary_test -> ui.box -> Equal weight. Buttons Btn1, BtnA, B, C
do not resize when resize the window.
ref T5487
Since the EO APIs are defined as weak symbols, invalid definitions of
EAPI lead to runtime crashes on non-public APIs. This is a fix following
a series of changes wrt. EAPI definitions.
There is a problem with the previous version. The object can still be
alive due to the use of manual_free in evas. So you wouldn't be able
for example to remove a callback from an object that hasn't been
destroyed yet. If that callback is triggered by the destruction
of the object, you would end up with an unexpected and impossible to
prevent effect of access after free on a callback that you had removed.
Not sure if that still solve the original problem that the code was
trying to prevent in Ecore_Evas.
with deferred surface creation the first canvas change of hints may not
be able to trigger protocol methods for size hints, so ensure that hints are
set
If we're not ticking already when a new animator is started then we have
to wait for a vblank to get a tick. That's not great.
If we can, use the time of the last vblank to generate an immediate tick
to avoid this latency.
Since the engines can call the flip functions, we need to protect the
ticker from missing those flips. Thus, we let ecore_drm2, which obviously
sees all flips, track them.
So, this is maybe not the best fix. The question is should we be able to
get efl_data_scope_safe_get return the object private data, when we are
currently executing the object EFL_EVENT_DEL callbacks. Right now we don't
and this lead to bug where we wouldn't have been able to destroy a callback
and get that callback triggered later on destroyed data (I had a crash in
terminology). I have switched back to the not _safe_ version which doesn't
enforce this, but that might not be the only place that need a fix.
Bryce Harrington
Guilherme Iscaro
Jean-Philippe Andre
Thiep Ha
Gustavo Sverzut Barbieri
Vincent Torri
Cedric BAIL
Derek Foreman
Mike Blumenkrantz
Amitesh Singh
Marcel Hollerbach
Jihoon Kim
Al Poole