during cursor free a move cb seems to add another job again after it
wss already deleted during the free process, so just clear the job
really late instead. valgrind found this one
@fix
If pointer is processed by a container in its POINTER_MOVE event
callback, then clickable calls efl_ui_clickable_button_state_reset not
to be clicked by efl_ui_clickable_unpress.
e.g. Efl.Ui.Active_View.View_Manager_Scroll sets pointer processed in
POINTER_MOVE event callback not to click button during scrolling.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9204
Summary:
pd-> surface will try efl_xref whenever surface_set is called.
desturctor is called from a subclass, ref and unref do not match.
So, Add this condition temporarily.
Test Plan: N/A
Reviewers: Hermet, smohanty, kimcinoo
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9235
Summary:
We are adding A object area to the redraws rect when object stack is changed
from (1) to (2) if A object is not mapped.
(1)
┌────────┐
│Object A│┐
└────────┘│
└────────┘
(2)
┌────────┐
│┌────────┐
└│Object B│
└────────┘
But if A object is mapped, then we are adding only part of A object area.
(part of A)
┌───────┐
│┌──────┘
└┘
So the result of stack change is (1) not (2).
This patch set is adding restacked mapped object to the restack_objects array,
after changing the stack of mapped object to add correct redraws rect.
Test Plan:
{F3727281}
{F3727280}
{F3727279}
(1) Build and Run attached example on software_x11 engine
(2) Mouse down on upper image - the image starts to use map.
(3) Then mouse up - upper image should go under the below image.
But, the changed result is NOT rendered.
Reviewers: Hermet, jsuya, zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9183
this adds a testsuite to emulate and check the usage of buttons in the
spin button widget. This also verifies that the correct events are
emitted. (For now, the testcases from spin are also copied over, since
they inherit from each other)
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9232
before the spin event for changing the value was called twice if you
changed the value by the entry. Additionally, the changed,delay event is
not emitted when the value was changed via the arrow buttons.
This corrects this, additionally, this enables the delay timer when
focus is gone, this is expected and should be supported by the API.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9231
this reduces the amount of code needed in the widget itself,
additionally, the theme now follows a scheme.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9230
there is no reason to store those two times in the internal data, as
they do not change at all. Additionally, saving the direction in the
internal data has also no reason, since it is *always* used in the call
after the setting, so this makes this a parameter.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9229
this makes the code more readable, and reduces the amount of events we
are subscribing to.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9227
doing this in pressed is kind of weird, if you are on a touchscreen,
missclick, and move the finger away, the entry is already transformed,
which is weird, this fixes that.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9226
this was just reimplementing existing behaviour. This can be done more
easily
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9224
this commits introduces unified behaviour for the users of the range
interfaces. This includes:
- The same errors for limit_set errors
- The same errors for value setting outside the range
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9241
this tests for the correct event emission. And checks the wheel
interaction.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9221
Some docs have been filled with placeholder text ("TBD") or with preliminary
text (marked with //TODO).
Having 0 doc warning we can now enable Warnings as Errors in mono, and in Eolian later on.
Summary:
this fixes a trivial leak where a string is leaked at the end of the function.
it is not significant, but it still appears in leak detections.
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9124
Summary:
Update eolian_cxx to recognize the new keywords `slice` and `rw_slice`, so it
can generate the corresponding types `Eina_Slice` and `Eina_Rw_Slice`.
Reviewers: lauromoura, felipealmeida, q66
Reviewed By: q66
Subscribers: cedric, bu5hm4n, #reviewers, segfaultxavi, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9237
View is something that is expected in the context of MVVM, so using it somewhere else is
going to lead to some confusion. Spotlight does descrive the objective of all of this
widget in actually a more explicit way as they all give the spotlight to one sub widget
at a time.
I have also renamed the View_Manager to be just Manager as the View there wasn't useful.
this commit ensures 2 things:
1. This ensures that the parent is not evaluated when there was no state
changed, this cuts down roughly 30% of the calls to full_eval
2. This ensures that we only listen to parent manager changes when we
are actaully registered. This reduces the amount spend in event emission
a lot.
This class helps widgets which contain a numerical value and must display it,
like Progressbar (units label), Spin, Spin_Button, Slider (both units and popup
labels, in legacy), Tags (when in shrunk mode) or Calendar (year_month label).
Previously this was a mix of interface and mixin: widgets had to support setting a
formatting func, and the mixin offered support for formatting strings, by setting
an internal formatting func. On top of that, the spinner widget supported "special
values", a list of values that should be shown as certain strings instead.
This has now been simplified and unified:
Widgets including this mixin can use the formatted_value_get() method which accepts
an Eina_Value and returns a string. Thats's it.
The mixin adds three properties to the widget (format_values, format_func and
format_string) which users can use to tailor formatting. The widget does not need
to know which method has been used, it just retrieves the resulting string.
This removes a lot of duplicated widget code, and adds functionality which was
missing before. For example, all widgets support passing a list of values now.
Widgets must implement the apply_formatted_value() method so they are notified
of changes in the format and they can redraw anything they need.
Tests have been added to the Elementary Spec suite for all cases.
Legacy widgets behavior has not been modified, although a few needed some code
changes.
from now on, the "changed" signal is only emitted on radio/check buttons when
the user interacted with this object. NOT due to the API change.
However, in the eo-api the event is emitted all the time, due to user
interaction, AND due to API interaction.
ref T8042
Summary:
Add a property (show_progress_label) to allow controlling whether the progress
label displaying the exact progress is shown or not.
This was possible in Legacy but the functionality was lost in Unified.
Updated elementary_test to showcase this property, and also the other label
formatting options, which where not tested anywhere.
Added a simple progressbar unit test. It only checks that retrieved value is the
same as the set value, so it is more of a placeholder for future tests.
**This is needed by a future patch which will introduce more formatting options that clash with the current implementation.**
The presence of a formatting function was used to decide if the progress label was shown or not. This explicit property simplifies things.
Test Plan:
Everything builds and passes tests.
`elementary_test -to Efl.Ui.Progressbar` should show a few more bars with different formatting labels, and a checkbox to toggle rendering of one of them.
Reviewers: bu5hm4n, zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9202
Summary:
Both C strings and eina stringshares are bound as regular strings in EFL#, as
working directly with these types would demand unnecessary hassle from the user
viewpoint.
But for eina containers this distinction is important, and since C# generics
do not provide a convenient way of dealing with the same type requiring a
different management based on some other condition (at least not without
compromising the usability for other types), we added a simple `System.String`
wrapper named `Eina.Stringshare` that works as a placeholder for signaling
this distinction.
Working with this class should be transparent in most use cases because it
converts to and from `System.String` implicitly.
It also implements equality/inequality methods for easier comparison with
strings and other stringshare objects.
Add new methods and a new container element trait for dealing specifically
with `Eina_Stringshare` elements.
Adapt eolian_mono to identify and generate the proper placeholder in methods
that require stringshare containers.
Remove some direct uses of DllImport-ed functions in favor of more flexible
manual binding methods.
Move `Eina.Stringshare` DllImport directives to a static class named
`NativeMethods`, in accordance with the code design warning CA1060.
Also add a TODO comment to move all other DllImport directives to this class.
Change parameter of the method `Efl.Csharp.Application.OnInitialize` from
`Eina.Array<System.String>` to `string[]`.
This will make this API more similar with the default C# way of receiving
command line arguments.
Add tests for containers storing stringshare elements.
Reviewers: felipealmeida, lauromoura, segfaultxavi, bu5hm4n
Reviewed By: lauromoura
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9178
Summary:
With this commit it is now possible for a class that inherits from a C# binding
class to be instantiated from native C code. It only has to provide a
constructor that receives an `Efl.Eo.EoWrapper.ConstructingHandle` struct,
and which calls the base binding constructor passing it.
For example:
`private Type(ConstructingHandle ch) : base(ch) {}`.
Add some test files to validate the proper behavior of this feature.
Add some small fixes in generation contexts in order to properly
generate base constructors.
Depends on D9070
Test Plan: `meson test` and `make check`
Reviewers: lauromoura, felipealmeida, segfaultxavi, woohyun, YOhoho
Reviewed By: YOhoho
Subscribers: YOhoho, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9071
Summary: this is actually a new class, it should be included here.
Reviewers: zmike, stefan_schmidt
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9200
Summary:
Previously, view position was moved by click because transition
information was initialized in mouse move instead of mouse down.
Now, transition information is initialized in mouse down so view
position is not moved by click.
Test Plan:
1. Run Efl.Ui.Active_View Scroll
2. Click Next button 2 times
3. Click Button Page
Or
3. Drag Button Page a bit to the left and click multiple times
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9173
EFL_EVENT_FOCUS_IN is wrong here, EFL_EVENT_FOCUS_IN is called on object
that received object focus. Not canvas focus, however, the code in the
callback there seems to be mainly for canvas focus handling.
Additionally, in evas_events, the event handler that was listening for
the canvas focus in / out events expected a event type, which is also
not correct, because the canvas focus in / out does not have one. In
order to catch such errors later more easily, there is now a safety
check, so we really fetched the correct seat.
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9191
it looks like this was left out during initial writing of eo-based eventing,
but based on the description, the intent was to have a separate cancel event
which was emitted just prior to the 'up' event using the existing state
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9184
Summary:
this doesn't seem to serve a purpose anymore and there's no point in
keeping it in tree
fix T7866
Reviewers: woohyun, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T7866
Differential Revision: https://phab.enlightenment.org/D9176
Summary:
this also adds tests verifying that EFL_EVENT_KEY_DOWN / EFL_EVENT_KEY_UP are emitted
and passed with the correct event types, and fields on the event object.
Depends on D9166
Reviewers: zmike, segfaultxavi
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9167
This restricts disallowing value types to containers that can own
them.
It also disallows usage of @owned on those view-only containers,
as that makes no sense.
Add a new function in the Eo API in order to provide more options on object
instantiation for binding creators.
For the Eo lib to be able to construct objects that inherit from bindings in
many languages we should provide a way for bindings to call different kinds of
constructors, in a way that simply overriding the `efl_constructor` method is
not enough.
We need a way to differentiate at construction time if the Eo is being
constructed from C or from the binding, because if it is the
former we need too call the inherited object constructor from C and instantiate
a new object, and if it is the later we need to avoid instantiating a
new object because we are already in the middle of the process of creating
a new one.
`efl_constructor` alone does not provide any way of distinguishing between
those situations, so, being able to pass additional information for
efl_add_start (like a custom constructor pointer) is necessary to make the
right distinction.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9070
Summary:
efl user can now specify colors by there names ( not only Hex RGB/RGBA values), which is very convenient specially for first time users (where user may think it is supported by default)
<color=#FF0000> == <color=red> == <color==RED>
there are two main types of color names and values ( X11, web colors), here we are using X11 color.
============
Update for documentation pages should be added like:
https://www.enlightenment.org/_legacy_embed/evas_textblock_style_page.html#evas_textblock_style_color
I do not know how to update it :(
Test Plan:
```
#define EFL_EO_API_SUPPORT 1
#define EFL_BETA_API_SUPPORT 1
#include <Eina.h>
#include <Elementary.h>
#include <Efl_Ui.h>
static void
_gui_quit_cb(void *data EINA_UNUSED, const Efl_Event *event EINA_UNUSED)
{
efl_exit(0);
}
static void
_gui_setup()
{
Eo *win, *box;
win = efl_add(EFL_UI_WIN_CLASS, efl_main_loop_get(),
efl_ui_win_type_set(efl_added, EFL_UI_WIN_TYPE_BASIC),
efl_text_set(efl_added, "Hello World"),
efl_ui_win_autodel_set(efl_added, EINA_TRUE));
// when the user clicks "close" on a window there is a request to delete
efl_event_callback_add(win, EFL_UI_WIN_EVENT_DELETE_REQUEST, _gui_quit_cb, NULL);
box = efl_add(EFL_UI_BOX_CLASS, win,
efl_content_set(win, efl_added),
efl_gfx_hint_size_min_set(efl_added, EINA_SIZE2D(360, 240)));
efl_add(EFL_UI_TEXT_CLASS, box,
efl_text_markup_set(efl_added,
"<color=red>this is red color line(color = red)<color><br>"
"<color=#0000FF>this is blue color line (color = #0000FF)<color><br>"
"<color=gray>this is gray color line (color = gray)<color><br>"),
efl_gfx_hint_weight_set(efl_added, 1.0, 0.9),
efl_gfx_hint_align_set(efl_added, 0.5, 0.5),
efl_text_multiline_set(efl_added,EINA_TRUE),
efl_pack(box, efl_added));
efl_add(EFL_UI_BUTTON_CLASS, box,
efl_text_set(efl_added, "Quit"),
efl_gfx_hint_weight_set(efl_added, 1.0, 0.1),
efl_pack(box, efl_added),
efl_event_callback_add(efl_added, EFL_UI_EVENT_CLICKED,
_gui_quit_cb, efl_added));
}
EAPI_MAIN void
efl_main(void *data EINA_UNUSED, const Efl_Event *ev EINA_UNUSED)
{
_gui_setup();
}
EFL_MAIN()
```
Reviewers: woohyun, bowonryu, segfaultxavi, vtorri
Reviewed By: segfaultxavi, vtorri
Subscribers: vtorri, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9153
Summary:
C# `Eina.Value` now has builtin support for `EINA_VALUE_TYPE_OBJECT`.
To avoid ambiguity with the `Set` method overloads, explicit casting
operators were used for wrapping/unwrapping `Efl.Object` instead of
implicit ones like for other value types.
Thus, to initialize an `Eina.Value` from an object, you can use the
following:
`var v = (Eina.Value)myObj;`
Reviewers: felipealmeida, vitor.sousa, segfaultxavi, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9164
this object is swallowed into a layout, which means the layout will be managing
this property
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9151
You can now declare errors like this:
error Foo = "message"; [[documentation]]
Then you can use them as types like this:
foo {
return: error(Error1, Error2, ...);
}
They have a separate type category and storage. They are checked
for redefinitions the same as anything else though. This does
not add any generator support nor it adds any advanced checking.
Ref T6890