refactor AW_file.cxx

[epruesse]

The current file chooser API is fragile and incompatible with GTK provided choosers. It may therefore make sense to refactor.

Concept:

• Use only one awar to back widget. Path mangling/separation can be done with functions from core.
• Incorporate sub-widgets:
  • Make "suffix" pattern a drop down using a name:pattern list supplied at widget creation time. (No-one ever wants anything but typical file types or all=*)
  • Filename field only for "SAVE" mode.

[westram]

Replying to epruesse:

Concept:

• Use only one awar to back widget. Path mangling/separation can be done with functions from core.

Requires changes throughout, as much code depends on existence of the 3 awars used currently.

• Filename field only for "SAVE" mode.

Filename field can be disabled by removing the corresponding at-label from xfig.

Accepting ticket because i need to do some changes for #263

[epruesse]

For completeness, the rest of my "original plan" as #263 is affected as well.

None of the OS or toolkit file choosers allow "show no directories". So if we moved to say the GTK browser, most of AW_file would have to remain just for the AWTI import/export filter selection.

The concept of using the file chooser to select import/export filters probably sounded elegant at the time. It has it's issues though. For example, if we want multiple directories, we run into the "duplicate filename" problem. Also, I'd like to see some extra features in AWTI that would be easier to do by parsing all the filter into memory anyway:

• show human readable name instead of filename in selection list
• display long description for selected filter in second box
• display preview result of parsing/exporting one sequence in third box
• remove or fix autodetect (consensus among seems to be "doesn't work")

I didn't implement any of this at the time, because the next step would be GUI-designable import/export filters. For export filters, I think "|nds()" would be cool, e.g. so that the can configure what he/she wants in the FASTA header w/o having to write a new filter.

[westram]

Yes, AW_file can be crunched aftermerge.

[westram]

Replying to epruesse:

For example, if we want multiple directories, we run into the "duplicate filename" problem.

No problem - duplicates can co-exist.

Also, I'd like to see some extra features in AWTI that would be easier to do by parsing all the filter into memory anyway:

• show human readable name instead of filename in selection list
• display long description for selected filter in second box
• display preview result of parsing/exporting one sequence in third box

No need to load filters to provide that. Can be done in callback bound to file-name awar.

• remove or fix autodetect (consensus among seems to be "doesn't work")

If autodetect fails, the import-filters need to be fixed

[westram]

gtk-port is dead

[westram]

Ticket retargeted after milestone deleted