@Jaehyun_Cho I think this event should either be on the window or on the application object. I don't think we want any of it to go through Ecore_Event.

If we want that, should I take care of it ?

What is the status of this task ?

What is efl.range ? I can only find efl.ui.range, and I don't think this is what you are talking about.

I agree with @SanghyeonLee no silent work around solution for users. This create trouble. What is the status of this task ?

Is this an enable/disable model ? If so, it can be implemented trivially by inheriting from the Boolean model. The main question being what kind of API do you want on top of it. Do we want a top level function that allow for example to define the state of an item to disable/enable without going through fetching the child object and setting its property ? Any other idea of what such a Model should provide ?

Yes, for non homogeneous case, we should have a callback that only update small portion at a time and doesn't over consume the main loop time. We can push an estimate of the scroll size by using an average of the currently calculated item. That is I think our best strategy there.

There is no future to get property. You need to watch for an event if you want to manually get notified of value being changed, but you can always get a property synchronously by doing a property.get. In general, most user should not have to care about that as they just need to do an .connect and things would be taken care of for them by the widget.

If I remember correctly, I think I was thinking of using a simple composite boolean for the multi selection case. As the Efl.Model_Composite_Selection inherit from it, if there are helper and API user-convenience function you are thinking of, it would indeed make sense to add the non exclusive mode to Composite_Selection and provide the helper there. Do you have a list of helper you are thinking of ?

Btw in the above example, I would do a ModelConnect on the multi factory for the property "icon" to be connected with the imgFac and due a simple connect("label", "another-property-in-the-model");

I don't understand in the example why you would have to write any code in a multi style factory at all. The idea would be to connect a property on the factory that would be used to decide which subfactory is called to instantiate that item. For example :

Also observable are full size Eo object, this will result in a very heavy implementation in term of memory use.

I have no idea why it was done this way in the first place.

Uh, this one is tricky. I think it is ok.

@felipealmeida wouldn't that also solve the connect problem of not knowing what are the available property on an object ?

@bu5hm4n Hum, that would indeed be an idea.

The arguments is that we have multiple example of bugs created in our code base due to the lack of type checking on the data type which will lead to crash in bindings. As relying on the user to always be right on calling event emit with the right data, seems badly placed faith, it seems we need a fix. As we need a different type checking for each event, it will result in a number of C function being added. I think this is fine. If you have other idea or proposal to avoid having the wrong data being send down the event emit path to end up crashing bindings, I am open to alternate solution also.

What is the state of this task @q66 ? I think I still see some potential bugs here that this would address.

Ah, yes, this event are special and you need an early way to register on the main loop.

This was fixed in master with 0c1eab0cf999db94164b70a80cc3941561a26844 . I will backport that to efl-1.20 branch. The commit log doesn't seems to know why this is happening, which means there might still be a deeper problem. @stefan_schmidt you might want to keep an eye opened for this problem.

This seems to be a work around MVVM pattern. The idea of MVVM is that all the decision logic is put into a ViewModel that act as a proxy for the View. This ViewModel would be were you make the choice for the style for example. If you move the decision making out of the MVVM pattern, you are breaking the automatic chain that was there and you can't build automatic test that do not rely on UI for example as the proper information is not exposed inside a VM property.

Is this still a problem ? Is there a reason this has not landed ?

This sounds interesting, where can I find the lottie-player library ?

This kind of trigger a fresh read for me on properties_get. I see a problem in general with the way it is used. A class can create new property on the fly (which is exactly what the boolean composite model does). I have created a task T7464 to track and discuss this specific issue. Until that one is addressed I am not sure we can land this patch even with correction I point out here.

Please get rid of seg_array. This is not something that make sense in term of public API at all. Don't forget that Eo object are public API meant to be used by bindings and others developers outside of EFL tree.

Why would we need Ecore_Event in Eo ? Do you have use case for it ? Duplicating legacy in Eo API is not a good enough justification in my opinion.

Seems everyone is agreeing here and that we are following practice of other toolkit/environment with this idea, so I do also support @Jaehyun_Cho proposal.

Could you do some more improvement on this ?

Not saying that a singleton is the right answer here, but there is multiple way to provide it with Eo. A simple way is to have a @class function that will return the same object all the time, that is very close to what @lauromoura is proposing. The other way are to implement a constructor or a finalize function, check if it is not the first time they get called and if not, return the first object created. I personally prefer the @class function as it is easier to read and doesn't have strange expectation.

This is interesting. I would like to see what is the call trace for most of this step_set. One of my guess is that this is happening in evas render while building the various object array. A long time ago, there was a cache to avoid rebuilding them during each loop as this array really don't change, but because Evas_Map was hard to handle and make sure it wasn't impacting the array content, I didn't bother at the time as it was not a very common use case. So when an Evas_Map is present, the cache are disabled. That was ok, 10 years ago. It might not be ok anymore today.

In D7030#122008, @kimcinoo wrote:

@cedric I would like to share the issue.
An application which is works on evas gl engine calls evas_object_image_memfile_set in a timer callback.
The evas_object_image_memfile_set is using eina_file_virtualize with copy == TRUE.
This newly allocated memory is kept by the cache and never released only after the cache deletes related Image_Entry.
So memory usage becomes bigger and bigger whenever the timer callback is called.

I don't think this is a good idea. The image is read only mapped by the kernel in memory and can be dropped by the kernel at any point in time. It is also shared with all other process. It is basically "free" for the process. I don't think there is a good reason to account for this.

So I put this in place as it was not possible to know if the parent was invalidating or not as efl_parent_get will return a valid parent chain during invalidation when is_invalidating is true. Basically you could know with efl_parent_get != NULL and efl_invalidated_get == true that the parent was currently invalidating itself. With this patch, we don't know anymore. Checking my usual pattern with E, Terminology and Elementary_Test doesn't yield any issue, so it might be ok actually. So I will land this serie, but if this trigger other issue, we might want to revert to the current behavior and change the caller to check this information correctly.

I agree with @Hermet ! Good to see you back !

Should be fixed by 2a5dc744083e2b227bbdfdcaf2c834298d72fa5f

No, I have tryed to figure out how that could be happening, but couldn't. Basically they are zombie object still present in the canvas when it is getting destroyed. It is a weird kind of zombie. Some where surviving as they were overriding efl_parent_set, but this is not the case for those. I haven't been able to understand what is happening. The good side is that it doesn't trigger a crash nor a use after free, the bad side is that it give little information of what is going on.

I haven't landed this one as this is still pending investigation with T6879, but I am giving up the only laptop where I see this crash today and don't have much time digging in. So there will be a call to be made if nobody understand why there is a crash to revert this patch or keep it @stefan_schmidt .

Hum, this might be related to the use of a static variable with no fork and parallel use, it might get to zero while it shouldn't. Maybe making that a general variable and doing a reset to 5 every time we do a test would solve this issue.