docs say return true on succesas, false on failure. adding a rect we
already added is not a failur. it's an optimization to a NOP. so fix.
this was brought up by and fixes T6669 ... but in the opposite way.
the format string checking was just ... wrong. it didnt' handle %%. it
didn't handle constant strings with no format in them... now it does.
fixes T6697
@fix
use sizeof the buffer rather than constant in snprint and 0.5 rather
than .50 which almost looks like a typo... :) also use correct escape
for % (%%%% so it becoems %% which is correct for a fmt string yto
produce %)
Summary:
efl_part macros are using each widget's internally defined
default_part_get() functions to get default part name.
This might potentially cause errors when future widgets
inherits the widget but not overriding Efl.Text.text and
Efl.Content.content.
Reviewers: jpeg, cedric, woohyun, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5797
this seems to be the only place where the related components are
explicitly used
neither of these components have fork-safe connections, so there is no
benefit to calling them during quicklaunch init
stealing the message data here prevents events which aren't being flushed from
ever being usable again and is unnecessary since the free callback will be
automatically called during the destructor
ref 5dd52fd09b
Before solving following problem in Efl.Ui.Check
https://phab.enlightenment.org/T6673
The changed callback is called with opposite value,
if application is using Efl.Ui.Check with state pointer.
The reason is that the changed callback is called in
efl_ui_nstate_activate, and the value refered by state pointer
is changed only after the efl_ui_nstate_activate is called.
static void
_activate(Evas_Object *obj)
{
EFL_UI_CHECK_DATA_GET(obj, sd);
efl_ui_nstate_activate(obj);
if (sd->statep) *sd->statep = efl_ui_nstate_value_get(obj);
Summary:
This patch fixes a break of consistency of return data from ecore_event_del.
Before EFL 1.20, when calling ecore_event_add(ECORE_EVENT_SIGNAL_USER, event_data, NULL, &data);
The user data(data) is saved at event->data. and when user calls ecore_event_del(event_handler),
ecore_event_del returns event->data. However, current ecore_event_del returns pd->ev.
I think it is ABI break.
Test Plan: Execute test suite
Reviewers: cedric, raster, stefan_schmidt, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5786
If an output gets disconnected, we would still like to be notified of
that. In the _outputs_update function, we mark an output as
disconnected by setting output->connected and output->enabled to
FALSE. With this line in place (in the output_event_send function) we
would never get notified if an output was disconnected.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so scenario:
1. use ibus
2. have at least english input and japanese input (or korean etc.)
3. have 2 kbd layouts (english and greek).
4. enable "use system keyboard layout" in ibus advanced settings
5. switch to english input mode
6. switch to greek key layout
7. type and get english, not greek input as you should
@fix for both terminology and elm/efl entry/ytext input.
Efl.Ui.Text:
The EO file contains a lot of references to legacy Elm types, which are
defined in elm_general. They should be checked and moved over to
efl_ui.eot if necessary.
Efl.Ui.Multibuttonentry:
This class was originally supposed to be based on a Model Item but as of
now the API is still uncertain, so MBE itself hasn't been worked on
more. Disable this from EO-only apps until its API is fixed.
Ref T6666
after a fork, any existing connection objects can no longer be used,
but it's up to the user to destroy them. internally, this prevents
existing connections from ever being returned as valid connections
and creates new ones after a fork
also destroy fd handlers for connections to ensure that no data is
accidentally clobbered before the connections are cleaned up
The Efl.Access.Attribute is using key and value.
The value could be NULL. If the value is NULL, then following error occurs.
*error:
arguments to dbus_message_iter_append_basic() were incorrect,
assertion "_dbus_check_is_valid_utf8 (*string_p)" failed
in file ../../dbus/dbus-message.c line 2712.
This is normally a bug in some application using the D-Bus library.
Array or variant type requires that type string be written, but end_dict_entry
was written.
The overall signature expected here was 'a{ss}' and we are on byte 3 of that
signature.