This revision actaully fixes that and makes it shutting down in a few seconds.
Are you sure its a infinite loop, or just terribly slow? It takes here ~ 3 min. until the window is closed. It is faster with my recent gengrid patches ... :)
Probably all the gengrid tests
This is usally a indicator that the widget tree builds a cycle in the shutdown. I can open here a lot of windows and nothing happens, it might be depending on what kind of widgets are there. Do you remember which windows you opened ?
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?
No problem at all :)
Oh, sorry. my bad. i didn't install latest EFL. ignore my comment above :(
Why is ev->info invalid? Your funcrion here is called while the event caller is still in scope, hence this pointer is fully valid ...
? They are never accessed outside the function scope ...
Do not use local variable address as event_info. you can't access that outside the function.
After those patches: P277
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.
Mon, Mar 18
In order to integrate better with the C# ecosystem, we have do adapt. This should not be a big change in current C# code, as we moved on from that old all-interface API scheme.
That works too
Don't get me wrong, but this needs to be decided / done for this release, we cannot wait for new syntax, lets just go now with the syntax that is everywhere, and change it afterwards.
I intend to do away with const() as well as ptr() in the current form entirely, so having a new syntax is the better choice for it, besides, immutable by default is a better choice than mutable by default
Maybe we should just be able to have klass-types const'able... I would not create another new syntax for it tbh.
Or maybe, make them const by default and some kind of event tag to make it mutable where needed?
Understood. Do we need a way to make objects const when possible?
We need to have objects mutable as this is used in our API, see Efl.Input.Hold / Efl.Input.Event. Properties like processed are required to be set.
That sounds good to me. So basically the only types allowed are value types, objects and container types, minus list/iterator; everything is annotated without any qualifier, and everything is immutable and passed by reference, except objects. Maybe we should pass objects by const too? So that only @const methods can be called on it. That would make all event data completely immutable.
When something gets *passed* the type of the input and output is always the same. (where input is a call to efl_event_callback_call, output is the API user that subscribed to a event)
Objects are passed as a normal Eo*, this means event subscribers can call functions on that object.
Iterators & lists should not be allowed as event types.
Structs / buildin-types / containers are *always* passed as const pointer, with exactly ONE level of indirection. The types of hashes and accessors *must* be annotated as const.
I'd say that allowing less is always a good thing, as it allows for fewer errors/mistakes, so if we can do away with it, let's do it
Same with Efl.Ui.Popup.Anchor.
What? Are we going to change the API now?
Okay this brings up another questions, are we supposed to allow changing of struct fields in event callbacks ?
Hum, there is a side effect to being passed by values vs references. In one case events can not alter the value as it pass there handler. In the other, they can. Maybe we should have a "const" marker to specify explicitly this intent. I think this also make a stronger case to mark efl_event_callback_call a protected function and generate function that will have the proper type checking in their prototype.
I don't think we currently specify how things are *meant* to be; we need to come up with something.
Any proposals on this?
This is currently the most urgent ticket for the 1.22 release.
Still broken with that patchset.
Sun, Mar 17
@zmike Still happening ? I cannot reproduce this here. The test freezes from time to time (1/20 runs). But it never crashes ...
Sat, Mar 16
Fri, Mar 15
Okay a few breadcrumps: there is a object overlaying everything.
The object is the frame object added by _elm_win_frame_add. I don't know why it overlaps everything, and i don't know why its not below.
Sooo - I manaed to bring down the times. However, its still lagging, the scrolling experience its less than perfect. However, on every group_calculate we walk a list of 5K items just by the design of gengrid, and that is slowing things down *a lot*. Not sure what else we can do here ....
I think we have a bigger underlaying issue, *every* item of the 5000 items is realized, is that really intended ?
I'm not going to have time for a few weeks...
Thu, Mar 14
Oh, that's interesting. I had an issue on my filesystem yesterday which resulted in a stat failing all the time which would lead to an Efl.Io.Model to always be in error. The patch D8336 is solving the error path and might actually solve also this problem too. Would be interesting to see if that does the case.
Adding this to high, so we can make sure this is done before we do releases.
@SanghyeonLee some help on this for the upcoming 1.22 release would be appreciated