unified widgets should use unified api internally and also be more explicit
about which min size hint (restricted or user) is being set in order to improve
readability of code
when unified widgets also implement legacy wrappers, legacy api should be used
for the legacy objects
no functional changes
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9495
Summary: This is for backward compatibility for TIZEN Test cases for legacy
Reviewers: woohyun
Reviewed By: woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9519
this is the basic work for getting radio group as a single_selection
interface, which can be a part of mutli_selection. Which will come both
later on.
ref T8057
Differential Revision: https://phab.enlightenment.org/D9504
Summary:
the ids of the structs here are never negative
ref T7976
Reviewers: zmike, segfaultxavi, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7976
Differential Revision: https://phab.enlightenment.org/D9497
Summary:
Delaying the unregistering here ensures that there is not focus set call
while a object is beeing registered in the focus manager.
ref T8081
Reviewers: zmike, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8081
Differential Revision: https://phab.enlightenment.org/D9513
Summary:
the behaviour here is that the next item according to the direction is
getting focused. This sounds easy but is quite complex given the fact
that the items might be hidden. This is the first draft for this, to see
how good it performes.
Reviewers: zmike, stefan_schmidt, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9496
internal
These functions are not used in efl wayland clients nor are they used
in Enlightenment. As such, there is no reason that they need to be
public API so this commit moves them to be Internal and updates
Ecore_Evas engine code to include the internal header.
ref T8013
Sorry to touch stable eo classes. there is name conflict issue between class and
property when binding language is generated from eo. for example in C#, compiler
error occurs.
```
src/bindings/mono/efl_input_hold.eo.cs(166,17): error CS0542:
`Efl.Input.Hold.Hold': member names cannot be the same as their enclosing type
```
This patch changes Efl.Input.Hold.GetHold/SetHold to
Efl.Input.Hold.GetInputHold/SetInputHold and generates Efl.Input.Hold.InputHold
property.
Note that CAPI is not changed.
ref T8093
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lauro Neto <lauromauro_>
Differential Revision: https://phab.enlightenment.org/D9484
People without X11 background would have a hard time understanding the difference
between key, key_name, key_code, etc.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9487
use HAVE_SYS_MMAN_H when including sys/mman.h and HAVE_MMAP when using mmap()
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9494
these need to be proxied to the internal image object to return
correct values
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9508
no idea what's going on here with new styling but this makes it look
like it should
ref T6649
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9502
these were used for clock module functionality that has since been removed
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9501
new widgets should use unified api internally
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9500
this was overly complex and never actually used
ref T7868
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9499
Summary:
`eolian_mono` now considers the implicit ownership of value types in arrays and
lists when generating ownership flags.
Also, update manual bindings for arrays and lists to no longer free elements
in the `Dispose` method when the container has ownership of the elements
but C# itself does not have ownership of the container; the elements will be
freed by whoever owns the container.
Modifying and removing elements will still free them though.
Re-enabled unit tests that required ownership of value type elements.
Reviewers: felipealmeida, q66, vitor.sousa
Reviewed By: felipealmeida
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9457
tracking some seemingly not so good asan hits on the eina file where
we're accessing an eina file already closed... so be extra paranoid
about it and set things to null after free/close...
this is meant to be implemented by entities that *can* be selectabled
(not to be confused with containers that can have selected contents)!
ref T8057
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9503
i dont know why, but something got badly mixed up, the selection APIs
for text and item ended up in the same interface, which seems ... weird
?
This commit splits that up into container_selectable and
text_selectable, there is no future plan on my list for text_selection.
The rest of this series is working towards removing
container_selectable, replacing it with a new interface. However, the
interface will stay until list_view is replaced.
The changes in the legacy code are removing the efl.ui.selection
interface from it, item emission is not depending on the inherited
interfaces, additionally, this interface does not provide any API, so
this should not be an issue.
ref T7766
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9498
efl_ui_clickable_util was only for efl_input_clickable interface,
but there can be more cases which want to connect object event
to specific action interfaces (such as scrolling) in the future.
For that extension, efl_ui_action_connector seems better.
ref: T7847
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9486
'toscan' is actually a view to 'mpath' memory, so freeing it first
would result in use-after-free. This is obviously only in the error
branch so it usually does not happen, but fix anyway.
CID1403022
While the previous code was I believe correct, coverity still
complains about it. Split it into two statements also to declare
intent.
CID 1402603..1402724
Summary:
Sorry to touch stable eo classes. there is name conflict issue between class and
property when binding language is generated from eo. for example in C#, compiler
error occurs.
```
src/bindings/mono/efl_input_key.eo.cs(272,26): error CS0542:
`Efl.Input.Key.Key': member names cannot be the same as their enclosing type
```
This patch changes Efl.Input.Key.GetKey/SetKey method to
Efl.Input.Key.GetKeySym/SetKeySym and generates Efl.Input.Key.KeySym
property.
Note that CAPI is not changed.
ref T8093
Test Plan: meson setup -Dbindings=mono,cxx -Dmono-beta=true
Reviewers: lauromoura, woohyun, zmike, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8093
Differential Revision: https://phab.enlightenment.org/D9483
zmike note: this class was not released at the point of this patch, the class
was only recently marked as stable
Summary:
this moves a bunch of api calls from elm_ to efl_. Those calls that are
called on the entry object are still elm, as well as access APIs, they
will have to be moved once efl_ui_text is usable.
Depends on D9475
Reviewers: segfaultxavi, cedric, zmike
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9488
having efl_ui_spin implementing efl.ui.range_interactive does not make
sense. Efl.Ui.Spin is a not interactive widget, so it should not
implement that interface.
ref T7897
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9475
spin_button should also implement formatted_apply, the label has a
different part name then spin.
ref T8097
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9474
if the spin button is skipped the spin is called directly, the label
will display the wrong value.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9473
this has been optional and unused by e for a very long time ot try
sync front-buffered software rendering with the wm/compositor. we may
as well remove the bloat that is here that is unused... it's been
inactive for many years anyway.
There was a weird profiling result that rectangles drawing is much much slower than images.
Checked reason, the computation rect clip area is the overload point.
I don't think it's necesary but we can simplely improve the performance here
by replacing native function.
I tested this by drawing 400 number of rectangles,
and this patch improved up abt 10 fps(sw), 20fps(gl).
@TEST CODE
MAX_SIZE = 400;
for(int i=0; i< MAX_SIZE; i++)
{
Evas_Object *rect = evas_object_rectangle_add(layout);
int x = rand() % WINDOW_WIDTH;
int y = rand() % WINDOW_HEIGHT;
evas_object_resize(rect, ELM_SCALE_SIZE(200), ELM_SCALE_SIZE(200));
evas_object_move(rect, x, y);
evas_object_color_set(rect, (rand() % 256), (rand() % 256), (rand() % 256), 255);
evas_object_show(rect);
Elm_Transit *transit = elm_transit_add();
elm_transit_object_add(transit, rect);
int dX = rand() % WINDOW_WIDTH;
int dY = rand() % WINDOW_HEIGHT;
elm_transit_effect_translation_add(transit, 0, 0, dX - x, dY - y);
elm_transit_repeat_times_set(transit, -1);
elm_transit_duration_set(transit, 1.0);
elm_transit_go(transit);
}
Summary:
The repeated counter in Efl.Input.Clickable_Clicked can be used to
identify double click or triple click.
Previously, the repeated counter in Efl.Input.Clickable_Clicked was
calculated within the time interval 0.1 second.
Now, the time interval for the repeated counter is increased to 0.25
second. It seems that 0.25 second is more appropriate to identify if the
two consecutive clicks should be considered together.
(e.g. considered as double click or triple click)
Moreover, in ecore_event and edje, 0.25 second is already used as a time
interval for double click.
Test Plan:
1. Run Efl.Ui.Button in elementary_test
2. Do double click or triple click the buttons
Reviewers: segfaultxavi, bu5hm4n, YOhoho
Reviewed By: segfaultxavi, YOhoho
Subscribers: YOhoho, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9485
Mike Blumenkrantz
Ali Alzyod
Carsten Haitzler
Marcel Hollerbach
Christopher Michael
Yeongjong Lee
Lauro Moura
Vincent Torri
Mike Blumenkrantz
Vitor Sousa
WooHyun Jung
Daniel Kolesa
junsu choi
Hermet Park
Jaehyun Cho