Page MenuHomePhabricator

elm file selector can't open subdirs in expandable mode
Closed, ResolvedPublic


try file selector test - enable expandable, try expand a subdir. nothing expands. a quick look seems to show a model problem - it's just not producing any output to filter for a child model...

raster created this task.Apr 28 2020, 5:51 AM
raster triaged this task as High priority.

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.

In short:

  1. _populate()
  2. _efl_filter_model_efl_model_children_count_get()
  3. _process_last()
  4. model is destroyed

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 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...

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)

However, i do not see how we should solve that in fileselector itself, with the API we have right now.
@cedric @felipealmeida How about we add a property_get for the key "children,count" which is asynchronous, and does only return 0 if its really 0 ? (That would need to be implemented in efl_io_model and efl_filter_model)

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