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
Summary:
Update eolian_cxx tests in order to remove forbidden eolian notations.
For tests with containers that support non-pointer types,
change `ptr(int)` to `int`.
For tests with containers that only support pointer types,
change `ptr(int)` to `string`.
Remove tests for features that are no longer meaningful with eolian new
restrictions.
Add a FIXME note to eina::range_array when used with eina::string_view.
Reviewers: lauromoura, felipealmeida, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers, bu5hm4n, segfaultxavi
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9236
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.
Assigning a method directly to a field expecting a delegate creates a
delegate on the fly. This delegate can be collected normally as any
collectable object. In dotnet the GC is more aggressive, causing this
delegate to be collected and C trying to call an invalid function.
To avoid this, we create a static delegate that will be passed to C. Its
lifetime will be tied to the static method it wraps.
Summary:
Encapsulate some parts of EoWrapper making them less accessible to lib users.
This can avoid unnecessary and risky usage of code that is only intended for
internal usage.
`inherited` field was made private and renamed to `generated`. Now its value
can only be obtained through the `IsGeneratedBindingClass` property.
`handle` field was made private.
`eventLock` was renamed to `eflBindingEventLock`
`ConstructingHandle` property set was made private.
Constructors that are used to create new EFL# managed objects by wrapping a
preexisting eo handle now receive a specific struct wrapping the handle pointer.
This can avoid faulty interactions with the Reflection engine used only for
generated classes that implement this constructor.
Test Plan: meson test
Reviewers: lauromoura, felipealmeida, YOhoho
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9212
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.
This only came up when we had gnutls native but not cross to find out
that we used the system pkg-config all the time to detect cross.
Making sure we use the correct tool to detect the cross dependencies.
Withj an updated ewpi in the docker image we can now enable more build
options. Examples are still disabled as there is a build break that
needs to get fixed first.
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
autotools has been removed. so that the autotools checking logic is not needed.
this patch removes them.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9198
Summary:
Values returned from C# Then callbacks must release ownership of the
underlying native value, so Eina code can clean it up nicely and avoid
the Wrapper flushing it early.
The same issue applied to the Async wrappers. In this case the value
passed as the Task parameter could be released by an `using` block
awaiting the value.
Also Future creation was then-ing the wrong handle.
Also add better exception messages.
Reviewers: vitor.sousa, felipealmeida
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9197
Summary:
Instead of 'expected' and 'actual', use 'lhs' and 'rhs', as it allows
the actually expected value to be in any position.
Reviewers: vitor.sousa
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers
Tags: #efl, #expertise_solutions
Differential Revision: https://phab.enlightenment.org/D9196
Summary:
Previously, if event info was not structure and it was a type defined in
eo, then the type value was not passed to the event info correctly.
e.g. if event info was Efl.Ui.AlertPopupButton enum type, then
default(Efl.Ui.AlertPopupButton) was always passed to event info.
Now, the given type value is passed to the event info correctly.
Reviewers: felipealmeida, lauromoura, vitor.sousa, bu5hm4n
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, herb, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9159
Summary:
Iterator and Accessors are views only, not owning the data they point
to.
Also updated the tests by handling some test data that were leaking.
Fixes T8036
Reviewers: vitor.sousa, felipealmeida
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers, segfaultxavi, q66
Tags: #efl
Maniphest Tasks: T8036
Differential Revision: https://phab.enlightenment.org/D9189
this verifies that EFL_EVENT_POINTER_CANCEL is emitted correctly.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9171
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
Some config definitions used in source code could not be defined during build config process.
- HAVE_XATTR
- HAVE_CIPHER
- HAVE_SIGNATURE
- BUILD_ECORE_EVAS_EWS
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9192
With the specsuite tests fixed now we can see that the build also works
with Fedora 30, so we can update the last missing jobs not having it.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9193
now we can consistently do event emissions inline in tests using much
simpler code
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9188
no need to manually include this for every file
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9187
the usual method is calc -> post render -> job to ensure everything is
set up. this simplifies getting to that job.
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9186
Any svg node could have its opacity value, we missed implementing it.
If a node have a opacity, it's opacity could be multiply with fill and stroke colors.
@fix
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