Allow BLAST to use a trim option when opening AlphaFold results

[Tom Goddard]

I'd like to be able to pass the BLAST tool a database-specific option that is used when a BLAST result model is opened.

When the AlphaFold tool Search button is used it runs the BLAST tool and shows AlphaFold Database results. When the user opens one of those results (by double clicking) I'd like the AlphaFold "trim" option (whether to remove extra residues from the ends) to be applied. But the BLAST tool knows nothing of this trim option, and the AlphaFold code that opens a BLAST result is in the BLAST bundle and has no way to get the trim true/false setting. This problem arose from Phil Cruz's request to add a "trim" option to the AlphaFold GUI, ticket #7238.

A possible way to handle this is that the AlphaFold-specific code in the BLAST tool would instead reside in the AlphaFold bundle that calls BLAST. It could call it with an instance that has methods for the AlphaFold-specific handling or results, which columns to show, how to get the values to show in those columns, how to open a result model. Maybe there are other simpler ways to do it.

[Zach Pearson]

I'm not very happy with the layout of the blastprotein bundle overall. Each bundle should be separated (as is appropriate) into gui, command, and API layers, with each layer calling into the lower one.

This should in principle allow me to get rid of stuff like chimerax.core.run. Any time I call another bundle's command, I should really just be calling some API in that bundle instead, and that bundle can manage the underlying command.

So what I'm thinking of right now is moving the AlphaFold database definition into the AlphaFold bundle for starters, then making it clearer that that database is a plugin to BlastProtein from AlphaFold. Then AlphaFold can manage it, and I'll figure out a way to implement this trim option.

[goddard@…]

I can add the trim option if you provide a way that does not need the trim parameter added to the multiple layers in the blast bundle.  The trim parameter should be something the BLAST bundle doesn't need to know about because the AlphaFold bundle will decide how a blast result is opened.

[Zach Pearson]

OK! I'll reassign the ticket to you when it's ready.

[Eric Pettersen]

Just FYI, in many cases chimerax.core.run is the preferred way to perform an operation, so the user can see in the log what the command equivalent of a GUI operation is.

[Zach Pearson]

Totally agree. Not saying things should run in the background, just that I'm thinking about whether or not it's an antipattern to call another bundle's command using chimerax.core.run.

[Tom Goddard]

I tried to make the blast alphafold database search handle version 3 of the database which uses different sequence description lines in the database, so it requires different parsing. To make the blast code correctly parse the description for the different version 2 and version 3 databases the parsing routine needs to know the database version that was searched. Currently the blast parsing code does not know the database version. Also the parsing code is in two different places: data_model/dbparsers.py AlphaFoldParser class and in data_model/database.py AlphaFoldDB class. Neither has access to the database version. Ideally the blast tool would allow the alphafold tool to register the AlphaFold database search and provide all these parsing details.

It looked messy to get the database version to the parsing classes that needed it since a change of arguments would effect the other databases too even though they don't currently support different versions. So instead I solved it in a poor way by deducing from the description line what version of the database it came from (only version 2 has a "|" in the description).

[Zach Pearson]

I think being able to register databases and parsers from other bundles is a good idea.

Probably the main impediment to implementing the trim option is settling on an acceptable UI.

Could be a command -- blast load bp1 result trim (clunky?)

Could be an additional right click option (2^{N menu entries for N user-facing option)}

Could be a checkbox on the results table -- but where

[goddard@…]

I don't think the trim option would appear in the blast gui.  I agree that is too much trouble for too little benefit.  I was more thinking the alphafold search command would have the trim option, or the search button on the AlphaFold GUI already has the trim option, and those would be used.  The problem is now that there is no easy way to get that option into the blast database handling code.  This trim option is also not worth a lot of work.  I make a lot of tickets not because I think they need to be done, but just so if a blast code reorganization happened in the future we'd know various things it should try to achieve.