Auto-deduce wether file contains morphology or cell, load accordingly.

[brenthuisman]

This is on current master, perhaps properly loading these files depends on Arobr v0.6, but I thought I'd mention it anyway.

E.g.: [error] NML file /home/brent/sync/julich/code/arbor-gui/data/c302-dd1-cell.nml has no morphologies.

In the open-morph file chooser, could we guess that .acc are Cable Cells?

[thorstenhater]

nml files have two modes: cell and morph. You'll need to use cell for this specimen.

[thorstenhater]

About the guessing part: I am not sure I understand.

[brenthuisman]

Could 'loading a file' be simplified to a single menu item, and let the tool determine what is in the file and load all that it can, and report something like:

Morphology loaded from c302-dd1-cell.nml. Cell data loaded from c302-dd1-cell.nml.

[thorstenhater]

Not really, how would you guess?

• NML files contain anything from channels to simulations
• acc may contain a full cell, so we might overwrite the decor state, or just morphology, ...

Also, your comment on the NML matter indicates that my comment was unclear.
NML morphologies can be looked up by <morphology id='foo'> or by <cell id='bar'>,
in Arbor's current implementation you need to say what you want and the GUI just reflects that fact.

[brenthuisman]

Not really, how would you guess?

Try 'em all and load what you can (and report what you do).

Also, your comment on the NML matter indicates that my comment was unclear. NML morphologies can be looked up by <morphology id='foo'> or by <cell id='bar'>, in Arbor's current implementation you need to say what you want and the GUI just reflects that fact.

(Try 'em all.) Look at what's there, offer a choice if multiple?

[thorstenhater]

So ... we are to square one, since the user has to choose anyhow?

[brenthuisman]

No. Workflow would be

1. click File > Open...
2. based on file extension, try to load what's found and can be loaded.
3. report on action in all cases/offer choice if needed (I don't know if it's common, but I suppose there might by multiple morphologies in e.g. an .nml file)

The user then does not need to know (because they will not in all cases) know what kind of contents the file they want to load contains, or even that multiple kinds of data can exists in a file (.acc and .nml may contain more than a morpho, and you may not want to force the user to chooce what to load based on the item clicked under File).

[thorstenhater]

The user not knowing what they are loading is exactly what we are shipping around here and I absolutely want them
to make a conscient choice.

Another example: SWC might be valid/invalid depending on interpretation. So, is this file bad and just accidentally loadable
in one way, or is this intended?

However, feel free to set this up, I currently lack the cycles.

[brenthuisman]

I guess what confused me, and therefore potentially others, is separate "Morphology" and "Cable Cell" categories. They are not mutually exclusive categories, so unless I know what's in a file, I don't know what to choose.

My assumption is that users will have files with unknown contents. Nobody starts from scratch.

I think the GUI is a good way to let users look at their data, and if you agree with that goal, giving some insight into the contents of their files aligns. I don't know what ways exist of checking the (kinds of) contents of for example an .nml file, afaik you either need to be able to read xml to some extent (I would check what pyneuroml offers, but it shows an unclear Java exception).

I could handle this issue, certainly! Just wanted to make sure you agree with the goal.

In terms of implementation: maybe when opening a file, an overview is shown of what was found in the file and what was loaded/can be loaded and how, integrating the filter and flavor dropdowns. E.g. for SWC, we can't make the flavor choice, but for NML, we could peek to see if there's a cell or morph and pre-select the option.

[thorstenhater]

Sure, that'd be the way to go:

1. Load any file,
2. Show what the GUI understands
3. Offer toggles load:y/n plus flavour combo boxes.

Troubles:

• It's a lot of work
• might include extending NML support in Arbor.
• loading things speculatively is risky

Go for it, if you have the bandwidth.

[thorstenhater]

@brenthuisman any updates?

[brenthuisman]

None.

[thorstenhater]

Did you have time to look into this? As a first step, you could change the title to something more in line with the actual problem/request.