Understood. Makes sense. This is a beta mixin anyway :)
Thanks a lot for a very detailed answer :)
Not even emitted from the class? Nice.
What is the Window Manager's selection? I mean, what is the difference between EFL's selection the WM's selection?
To be sure, EFL's selection is what happens when you select text (shift+cursors) in a text entry, right?
I clarified a bit what this task is about. I am not sure where these docs would fit, though.
The user-facing part (retrieving event info from an event struct) probably goes here:
But I don't know about the internal part (calling efl_event_callback_call). Maybe in the docs for efl_event_callback_call in Eo.h?
How many methods exist which accept an event_info?
This looks like an obvious fix, but how can I check the results?
New API elementary_test (Gesture) does not seem to be working for me at this moment.
Old API elementary_test (Gesture Layer 1, 2 and 3) all seem to be working just fine without this patch.
Makes sense and simplifies code. Builds and passes tests.
I am having troubles understanding how Index works. Please, correct me if I am wrong.
Negative indices only mean that you count from last to first, instead of first to last, right?
So, if a container has 4 items, you can access the first one using index 0 or index -4, and you can access the last item using index 3 or index -1. Correct?
In this case, the docs could be clarified a bit.
Also, some methods (like pack_content_get) accept the [-count, count-1] range, whereas other methods accept the [0, count-1] range (like pack_index_get). The docs for each method should clearly state the valid range.
I just reverted the landing in 8c39c0e2512732ed08a40552df52c4b4f791018f
Doc refs are OK, and everything builds and passes tests.
Using the language mechanisms for casting (obj as Efl.Ui.Button) sounds better than having a custom method, from an API point of view. I do not know how hard that is, though.
Understood, but eina_future_as_value() does not wrap an Eina_Future in the value, it wraps an Eina_Promise, so... misleading :)
Mon, Mar 18
This has broken the build for me:
../src/lib/elementary/elm_focus_legacy.c: In function ‘elm_object_focus_next’: ../src/lib/elementary/elm_focus_legacy.c:248:19: warning: implicit declaration of function ‘ELM_WIDGET_DATA_GET’;
The obvious fix is obvious.
What? Are we going to change the API now?
First off, thank you both for giving my brain the opportunity to hurt so much.
OK, thanks. I see there's a mild improvement in scrolling speed. It would be nice if this test output some numbers :)
Docs are a bit better now :)
Hmmm... I still get lots of errors on shutdown, including:
CRI<87656>:eo ../src/lib/eo/eo.c:1954 efl_unref() Calling efl_unref instead of efl_del or efl_parent_set(NULL). Temporary fallback in place triggered. ERR<87656>:eina_safety ../src/lib/efl/interfaces/efl_interfaces_main.c:105 efl_part() safety check failed: efl_ref_count(r) == 1 is false ERR<87656>:eina_safety ../src/lib/efl/interfaces/efl_interfaces_main.c:105 efl_part() safety check failed: efl_ref_count(r) == 1 is false ERR<87656>:eo ../src/lib/eo/eo.c:1988 efl_unref() Obj:Efl.Canvas.Layout_Part_Invalid@0x400000244779. User refcount (-1) < 0. Too many unrefs. ERR<87656>:eo ../src/lib/eo/eo_base_class.c:682 efl_del() Calling efl_del on object Efl.Canvas.Layout_Part_Invalid@0x40000005a335 with no parent is not advised any more. ERR<87656>:eo ../src/lib/eo/eo.c:1988 efl_unref() Obj:Efl.Canvas.Layout_Part_Invalid@0x40000005a335. User refcount (-1) < 0. Too many unrefs. ERR<87656>:eo ../src/lib/eo/eo.c:1988 efl_unref() Obj:Efl.Canvas.Layout_Part_Invalid@0x400000199835. User refcount (-1) < 0. Too many unrefs. ERR<87656>:eo ../src/lib/eo/eo.c:1988 efl_unref() Obj:Efl.Canvas.Layout_Part_Invalid@0x400000244779. User refcount (-1) < 0. Too many unrefs.
Which is the error that this patch is supposed to fix?
Failed: 39/300 Errored: 78/300 Success: 207/300
Failed: 28/300 Errored: 74/300 Success: 219/300
So this patch makes this little script a bit more helpful.
The example works now. Previously it was saying:
ERR<50510>: ../src/examples/edje/edje-multisense.c:42 create_my_group() could not load 'example_group' from multisense.edj: File Does Not Exist
Confirmed that this allows running the example without being in the source directory.
I guess autotools does not get a fix, but since it's going to be deprecated, it's not a big deal.
Confirmed that this fixes a segfault. Also, makes sense.
Confirmed: this fixes a segfault.
Builds and passes tests. Simple test apps (hello-cmd tutorial) can be compiled without defining EFL_EO_API_SUPPORT nor EFL_BETA_API_SUPPORT.
Sun, Mar 17
This removes ALL mono doc warnings except one. I want to land this! (but fix these issues first).
10 removed lines + 0 added lines = instant approval.
Fri, Mar 15
It only happens for me in the C# version, no in the C version. But at least I got a bit of a backtrace:
#0 0x00000000400378cb in () #1 0x00007ffff1b36cb7 in efl_canvas_group_need_recalculate_set () at /usr/local/lib/x86_64-linux-gnu/libevas.so.1 #2 0x00007ffff2efb270 in () at /usr/local/lib/x86_64-linux-gnu/libelementary.so #3 0x00007ffff60007f0 in () #4 0x00007fffffffc0e0 in () #5 0x00007ffff31add40 in _EFL_UI_FOCUS_OBJECT_EVENT_FOCUS_CHANGED () at /usr/local/lib/x86_64-linux-gnu/libelementary.so #6 0x0000000000000000 in ()
Fixed somewhere else.
Fixed somewhere else.
Fixed somewhere else.
Hooray for making things private!
(also, everything is still building and passing tests)
Would be nice if the commit message explained WHY this is needed (what is the problem being fixed). Otherwise, reviewers will have a hard time figuring out how to check this. That's the reason for the "Test plan" section.
- _StructConversion classes: Do they need to be public?
I'll create a task for it.
if (number_of_removed_lines > number of_added_lines) approve_patch_automatically();
Works as expected.
Thu, Mar 14
After that commit message you can submit whatever you want and I'll approve it.
Wed, Mar 13
I was hoping this would also fix the simple Hello World tutorial, which has never worked in the past 1.5 years:
Tue, Mar 12
Yup, this fixes the problem I was mentioning in D8244.
I have no further documentation concerns. I will let others do the code review.
Works again in my Ubuntu 18.04
Mon, Mar 11
Builds and I verified that the new geometry,changed event sends the correct geometry info, without any ERRs on the console.
Nothing wrong here.
Builds and works as expected.
Sure, no harm done, but until we add support for vars in mono, this does not have much impact there.
Fixes make distcheck as advertised. I cannot comment on whether this is the right way or not, though.