Yea....not going to happen

Mistake found, give me a few hours to run tests.

Invalid now....

Closing this. Removed the test from elementary, was a miscommunication there..

confirmed. it fixes it/works :) nicely done!

Just to note down the full chain of what is happening:

• _efl_filter_model_efl_model_children_count_get gets called
  • _efl_io_model_efl_model_children_count_get returns 2
  • _efl_io_model_efl_model_children_slice_get returns a valid resolved future [1]
  • returns 0 because no other value is known yet, but values should be available asynchonous.
• _process_last gets called. And due to this wonderfull api called _efl_loop_model_volatile_make kills itselfs, even if it has a parent available, the future returned in 1 gets killed, and thats the end of the story. (@zmike sorry, i did not notice we had this volatile_make call)

i did notice children was 0 ... but if it has already filled it in... then children would be > 0 ... (well the examples i was looking at was a dir with files inside - the filesel test). so... hrrm. that was one of the things i noted. children was 0. i was wondering what on earth could or would force a populate then perhaps to get children to appear. i got the idea that the child module already existed because the parent populate created it...

mhm i dont think so, the model created in _populate() is just the filter mode *and* it is created via efl_add_ref. In _process_last only that one ref that was taken is given up, the filter model itself is still alive...

I spent some time on this, and it seems that the model created in _populate() to generate the listing for this case is destroyed in _process_last(). This occurs due to efl_model_children_count_get() returning 0 since the underlying filter model is expecting to process asynchronously even though the io model has already filled in its file data. The model being filtered is destroyed before it can filter, which prevents any files from being processed.

it's not overly complex. no more than saying "you need to unzip the zip file to get to the readme" :) so it's there and it complies legally - it's shipped as intended and actually available for anyone wanting to look at it. i would argue 99% of people will never edje_decc or even know it exists ... so as an order of magnitude... they are both in the under 1% will even look :)

yeah from a Legal perspective I guess an overly complex way to get it is significantly different to not being able to get it :-)

i'd call it trivial as the data is there and is trivially extractable.

the license is there.

i can only assume the config was messed up and and bindings modifiers wee broken. i have removed he ability to select modifier in wizard - it's do it by hand in mouse bindings. better as it's more user friendly to be able to have documentation that universally says "alt+left click and drag to move anywhere in a window" and it will work unless the user has explicitly customized (an they should know then)

so what happened to make it not work????? odd.

After resetting the configuration by renaming the .e directory, Enlightenment works perfectly. Thanks to @jf_simon and bu5hm4n!
---Original---
Nach dem zurücksetzen der Konfiguration durch umbenennen des .e-Verzeichnisses, funktioniert Enlightenment tadellos. Danke an @jf_simon und bu5hm4n!

Thanks, so we will ignore it for the release and can backport a fix later (if needed)

@stefan_schmidt yes

zmike is right. if you want to also have some min hints of your own the trick is:

@stefan_schmidt I do not think there will be soon fixed for this issue.

It looks to me like you're setting size hints on a box, which would only have ever worked coincidentally at best since a box will overwrite those hints any time it recalculates.

Are you saying the code is incorrect? I'm duplicating the behaviour from within ephoto which worked in previous releases.

@ali.alzyod @AbdullehGhujeh is this something you consider to be fixed before 1.24? Its marked as a showstopper and I am trying to understand if there is work going on to fix this before the release or if it is fine to be fixed afterwards.

This has not been touched since 2018. @indefini can you still reproduce this with latest efl?

I consider it solved now.

It is OK for me now (after 9fd9a3b120fe).

This should be fixed in 1afb26428899cf24da45b73540f711ee27679fdb

I've spent some time looking into this, and I have questions. Based on the code in the elm_test case, can you explain how and why (in code terms) you are expecting the contents here to have a nonzero size?

Hmm...
After this patch, once killed it does not come back.
If I try to restart it manually from command line - it silently dies after ~20 seconds.