This patch was *REJECTED*. I don't understand why it was snuck in among
a batch of 24 other unrelated patches. That made me miss it originally,
but found it now. This is wrong and shouldn't be in.
This reverts commit 3f0d0daf0d.
Summary:
The size of the style pad isn't considered when the min value of the
textblock is calculated. In case of putting the lable that there is an
outline in the box, the letter is cut. So, I revised so that
evas_object_textblock_style_insets_get could be called after a
evas_object_textblock_size_formatted_get in
_edje_object_size_min_restricted_calc function. And then the style pad was
considered in the result value of the edje_object_size_min_calc.
@fix
Test Plan:
EAPI_MAIN int
elm_main(int argc, char **argv)
{
Evas_Object *box, *label;
Evas_Object *win;
elm_policy_set(ELM_POLICY_QUIT, ELM_POLICY_QUIT_LAST_WINDOW_CLOSED);
win = elm_win_util_standard_add("Font", "FONT");
elm_win_autodel_set(win, EINA_TRUE);
box = elm_box_add(win);
elm_box_padding_set(box, 10, 0);
elm_box_align_set(box, 1, 0.5);
evas_object_size_hint_weight_set(box, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
evas_object_size_hint_align_set(box, EVAS_HINT_FILL, EVAS_HINT_FILL);
elm_win_resize_object_add(win, box);
evas_object_show(box);
label = elm_label_add(box);
elm_object_text_set(label, "<font=default align=rignt color=#ffffff font_size=200 style=soft_outline outline_color=#ff0000ff>label");
elm_box_pack_end(box, label);
evas_object_show(label);
evas_object_resize(win, 500, 300);
evas_object_show(win);
elm_run();
return 0;
}
ELM_MAIN();
Reviewers: herdsman, tasn
Reviewed By: tasn
Subscribers: id213sin, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3426
Summary:
Use width of item format to position cursor.
Sometimes it becomes very difficult to
position cursor over item and selection
becomes very difficult as we position the
cursor once the input X coord reached end of the item,
like one attached in the test plan. So this patch
decides over 50% of item width for X coord reaches
to position it at start or end.
@ix
Test Plan:
Attached setup shows how difficult to position cursor at the end when clicked
over item and selection is also very difficult. Consider such case in mobile
device, its becomes impossible to position cursor at the end and selection is
too much difficult.
{F27036}
Also added test cases in evas test suite
Reviewers: herdsman, tasn
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3390
Summary:
- This function is deprecated, because del_full should be used instead.
- Still, the documentation specifies in which order the callbacks should
- be deleted.
Reviewers: Hermet, jpeg, jaehwan
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3459
Setup a listener to receive an uid from the compositor. If we already have
one during creation, aka we are re-connecting to recover a session, we provide
it to the compositor so it can look our attributes up based on it. Again hidden
behind and env var to avoid problems with other developments, for now.
ref T2922
To avoid trouble for other wayland testing we hide the session recovery work
behind EFL_WAYLAND_SESSION_RECOVERY. Without this env var being set we do not
bind the global.
ref T2922
when changing the type of a part which already has descriptions, it's
necessary to avoid copying any of the previous type-specific desc data
this should be the last of them...
@fix
in the case where a part is inherited, changing the type will lead to
broken part/program lookups for the part during resolving in write-out;
memcpy alone is not enough to fix this.
@fix
==24030== Invalid read of size 1
==24030== at 0x4A0AC77: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x598A9DC: _eet_dictionary_lookup (eet_dictionary.c:69)
==24030== by 0x598AA93: eet_dictionary_string_add (eet_dictionary.c:103)
==24030== by 0x598107B: eet_data_put_string (eet_data.c:857)
==24030== by 0x598213F: eet_data_put_type (eet_data.c:1433)
==24030== by 0x59895AB: eet_data_put_unknown (eet_data.c:4798)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x59894A4: eet_data_put_array (eet_data.c:4760)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5989617: eet_data_put_unknown (eet_data.c:4807)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5983E06: eet_data_write_cipher (eet_data.c:2396)
==24030== by 0x5983E92: eet_data_write (eet_data.c:2412)
==24030== by 0x406BC2: data_thread_head (edje_cc_out.c:674)
==24030== by 0x406D51: data_write_header (edje_cc_out.c:717)
==24030== by 0x40B52E: data_write (edje_cc_out.c:2439)
==24030== by 0x40563D: main (edje_cc.c:399)
==24030== Address 0xf45cb7b is 0 bytes after a block of size 347 alloc'd
==24030== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x414BAC: mem_alloc (edje_cc_mem.c:15)
==24030== by 0x41B66A: st_filters_filter_file (edje_cc_handlers.c:4718)
==24030== by 0x410EDA: new_statement (edje_cc_parse.c:229)
==24030== by 0x41227C: parse (edje_cc_parse.c:719)
==24030== by 0x412E5C: compile (edje_cc_parse.c:1044)
==24030== by 0x405624: main (edje_cc.c:394)
==24030==
==24030== Invalid read of size 1
==24030== at 0x4A0AC77: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x598AAFB: eet_dictionary_string_add (eet_dictionary.c:109)
==24030== by 0x598107B: eet_data_put_string (eet_data.c:857)
==24030== by 0x598213F: eet_data_put_type (eet_data.c:1433)
==24030== by 0x59895AB: eet_data_put_unknown (eet_data.c:4798)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x59894A4: eet_data_put_array (eet_data.c:4760)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5989617: eet_data_put_unknown (eet_data.c:4807)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5983E06: eet_data_write_cipher (eet_data.c:2396)
==24030== by 0x5983E92: eet_data_write (eet_data.c:2412)
==24030== by 0x406BC2: data_thread_head (edje_cc_out.c:674)
==24030== by 0x406D51: data_write_header (edje_cc_out.c:717)
==24030== by 0x40B52E: data_write (edje_cc_out.c:2439)
==24030== by 0x40563D: main (edje_cc.c:399)
==24030== Address 0xf45cb7b is 0 bytes after a block of size 347 alloc'd
==24030== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x414BAC: mem_alloc (edje_cc_mem.c:15)
==24030== by 0x41B66A: st_filters_filter_file (edje_cc_handlers.c:4718)
==24030== by 0x410EDA: new_statement (edje_cc_parse.c:229)
==24030== by 0x41227C: parse (edje_cc_parse.c:719)
==24030== by 0x412E5C: compile (edje_cc_parse.c:1044)
==24030== by 0x405624: main (edje_cc.c:394)
@fix
since it's now possible to inherit parts, it's possible that inheriting from
a different part type can lead to memory errors in the case where one part
has a larger desc struct than the other
@fix
this is not ideal since it triggers a client-side rerender of every object
which was clipped to the master clip (double render) and then this ends up
forcing the server to rerender the same area twice as well
not only that, it causes all surface damages to to be the size of the entire
window - framespace for every frame
@fix
while not occurring immediately before flush as in sync rendering, this
is functionally close enough that it will serve the purpose for which the
callback was intended, namely receiving a callback that occurs after render
update calculations have occurred but before flush happens
@fix
ref cbb447c878
Summary:
When a input device is plugged in, _cb_open_restricted() is called before creating evdev.
So setting fd value on evdev was failed in _cb_open_restricted() and also closing evdev->fd was invalid.
Using a eina_hash which has 'path-fd' pairs, we can find fd value after evdev is created.
@fix
Test Plan:
(1) Multiple input devices are connected. Their evdev->fd remains zero or initial value.
(2) When one of those devices are plugged out, fd leak would happen.
Reviewers: raster, zmike, gwanglim, stefan_schmidt, devilhorns, ManMower
Subscribers: cedric, jpeg, Jeon, input.hacker
Differential Revision: https://phab.enlightenment.org/D3428
The main reason is convenience for debugging when using GDB,
this will give a simple breakpoint for all safety check failures.
Also, this creates a more visible log domain (red).
The EINA_LOG_BACKTRACE thing is aimed at production environments,
so we can extract a backtrace from a log file post-mortem, but not
for continuous development of EFL itself.
I know this should make a few people happy.
Most eina log env vars mean "if loglevel <= val then print log"
but eina_log_backtrace was "if loglevel < val" which I thought
was a bit confusing. The default behaviour is unchanged.
Summary:
The socket API is different on Windows and on Linux.
This is the perfect example where we need to abstract the socket API in Eina :
1) to avoid all these includes specific to sockets
2) to avoid on Windows undefined behavior : close(socket); is undefined behavior if socket is indeed a socket
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3441
Summary:
When compiling on Windows, Evil.h must be included, so update Makefile.am
accordinglY
Reviewers: cedric, jpeg
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3439
Apparently a special font makes the vflip tests crash. vflip
definitely needs to be fixed.
I'm currently working on the filters, so I'll get back to these.
This is a temporary patch.
After the support of the X11 cursors on Windows, the cursors were set for the whole
window (even the borders). Now we let the system use the default cursors for the borders
and we use the cursors set by the API for the client area only
Summary:
Even if the given two cursor is NULL, it shouldn't be crashed.
@fix
Test Plan:
Test case included in Evas test suite.
Run "make check".
Reviewers: herdsman, tasn
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3422
we initted when we load and unload. this led to races with
locking/unlocking elsewhere as these expected us to be initted and we
were not yet. this fixes that!
@fix