Set and get functions are inconsistent one with the other. When set
function is used with a certain value, one expects the get function
to return this value.
We were copying a user defined string into a fixed size buffer
without doing any boundary checks. This commit fixes that.
Also cleaned up similar code that was using hardcoded numbers.
@fix.
Summary:
evas_common_language_from_locale_* functions kept static pointers
inside of its functions. Once these function was called, it was never reset.
It made big problems for harfbuzz and hyphenation. Also, Elementary
provides elm_language_set() API. Then we need to support it fully.
@fix
Test Plan: Test case for hyphenation is included in Evas test suite.
Reviewers: raster, tasn, herdsman, woohyun, z-wony, Blackmole, minudf
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3864
Summary:
Calculation for item highlight geometry is incorrect when item
is larger than viewport geometry.
This patch adjusts highlight geometry to fit visible item size.
Test Plan: enventor (look "Settings-Text Editor-Font Names" list)
Reviewers: Jaehyun_Cho
Subscribers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D3738
so efreets tmp file/cache/log file handling was broken, using
filenames in tmp and renaming them to a caceh dir that can be on
different filesystems. also log file should have been in a tmp dir ...
and subsidrs cache didnt get renamed properly at all and thus not
updated.
@fix
xdg runtime dir is NOT a tmp dir in the normal sense. it's not world
writable nor world readable. only for the user. using
eina_environment_tmp_get() would imply that it is a regular tmp dir,
not a per-user private only runtime dir. that is something else
entirely.
@fix
the only way to accurately calculate the "evas" size in the engine from
window geometry is to have the size of the frame available to subtract from
window geometry
window geometry is NOT framespace--framespace is the entire csd region, possibly
containing a shadow, and window geometry is explicitly the region occupied by the
window, ie. not the shadowed part.
not my ideal solution to the synchronization issue here, but I guess this is a
benefit of the unified tree
fix T3396
this is an event representing the "new" state of the surface after a
configure event. it must contain the exact states which could potentially
have changed in the configure in order to ensure synchronization between
csd states and window size.
ecore events for xdg-shell configures must be sent only upon receiving a
configure event since states are set by the compositor and not by the client
@fix
#hoorayforbeta
in the case where an icon existed upon having an icon object set, the previous icon
object would be orphaned while still being visible. the new icon would then never
be set into the csd.
@fix
this was broken if the compositor unset fullscreen without being prompted by
the client (eg. ctrl+alt+f). it also created timing differences for csd calcs based
on when the fullscreen call occurred in the render cycle
@fix
Summary:
the event XkbNewKeyboardNotify was never selected with
XkbSelectEventDetails so the event type could never occur.
The event is now each time emitted when a new event to the keyboard
happens. To clarify a bit: A new keyboard is always detected in x when
the set of keymaps changes.
@fix
Reviewers: raster, devilhorns, zmike
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3867
Efl.Flip is now the enum, the interface is Flipable.
We could even use names like Efl.IFlip a la Java.
eo_prefix is used to have pretty names in C. legacy: null
is removed from the enums. orient_x0 is removed and only
defined in C with #define
Summary:
Implement common interface efl_ui_progress and inherit slider and progressbar from common interface.
Currently legacy APIs will also call interface functions and later it can be deprecated.
This interface will be moved to EFL in src/lib/efl/interfaces when elementary is merged into efl.
Test Plan:
elementary_test -to 'slider'
elementary_test -to 'progressbar'
Reviewers: singh.amitesh, raster, tasn, felipealmeida, woohyun, cedric, jpeg
Subscribers: saurabhbunty, alok25
Differential Revision: https://phab.enlightenment.org/D3759
For windows, EAPI needs to be redefined as dllexport/dllimport.
Since we marked all EO APIs as weak, we had two different EAPI
macros: EAPI and EWAPI. Unfortunately, EWAPI was never redefined
(only declared inside Eo.h).
See also a1a506e13e.
See T3423. Thanks @vtorri for the report.
While eolian-gen was generating EWAPI (weak) class_get()
symbol declarations, they were implemented as EAPI (strong).
Not sure if this mismatch had any significant effect.
This patch tries to address T3423 (windows build).
The mismatch between EAPI and EWAPI might be the problem.
This fixes a crash in ecore_init, calling a weak function from
libefl that was resolved to NULL.
So, here's a fun thing happening with GCC < 5.3. Since a1a506e13e
all EOAPI and EO class_get() functions are weak symbols. This means
that all APIs inside libefl.so are weak.
As a result, gcc linker with --as-needed skipped linking to libefl
since not a single strong symbol from libefl was required by
libecore. This is actually a bug in gcc linker since we do in fact
use symbols from libefl, just weak ones.
GCC 5.3 seems to be fixed, so people with GCC 5.3+ will not
experience any build/runtime issue. The current patch is
a workaround that bug, by artifically creating a strong symbol
required by ecore.
Other libraries than ecore might also need to call
__efl_internal_init, if they end up not being linked to libefl.
Add a promise object to allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
The usage is like this in a .eo file:
class Foo {
methods {
bar {
params {
@inout promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Eo* obj, Eina_Promise** promise);
and a Eina_Promise_Owner for the implementation, like this:
void _foo_bar(Eo* obj, Private_Data* pdata, Eina_Promise_Owner* promise);
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Add two parameters for macros that generate API functions in Eo so
that the generation can be customized with macros used by Eolian.
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
I'm reverting this because according to jpeg it was possibly fixed in
5284b62e93.
I reverted this patch after his fix and followed his reproduction cases
and it seems that his second patch does indeed fix this issue so this
patch is no longer needed.
This reverts commit 0862b9d083.