zMapFeaturesetCreateID() and zmapStyleCreateId() and ZMapGFFSet and ZMapGFFSource could benefit from a review. (NB these structuire have been renamed ZMapFeatureSetDesc, ZMapFeatureSource The problem is that sometimes we want names normalised and sometimes we want them capitalised as given. Perhaps the best way woule be to have all key values as normalised and duplicate quarks used for display names. There are 86 calls to these functions, and this is not all the code that would have to be checked.
Styles have gff_source and gff_feature parameters. There are supplied by ACEDB and only used for GFF dump functions. This information is more appropriately handled by the GFFSource data structure, held in the view/window context_map->source_2_sourcedata hash table.
zMapViewLoadFeatures() is called for OTF data requests after the initial load, and featuresets etc are concatenated not merged. The server interface has some loose ends relating to whether or not the report all supported featuresets of just those requested, and currently theyeturn all styles not just those needed. Needs a tidy up.
Locus features are apparently created via some kludge which causes some problems when deleting features. This and the naviagtor-sets needs a review. see eg zmapViewRemoteRecieve.c #1601.
Migration from ACEDB requires featureset to column and style mappings which can be obscure. it is possible to extract this information by hand from otterlace config but this is not possible for users.
RC export/config could be used to dump this info to a file but due to scope issues it's really difficult to find that information where the functions get called from. This is tied up with view/window 'modularity' and there is a clear need to restructre some of the v iew and window data so that stuff that is needed by both modules is available. Currently some data (eg featureset_2_column) is copied but this is not ideal.
zMapFeatureGetColumnFeatureSets() is very ineffcient in that it scans all the featuresets for each column. An attempt to do this reverse mapping and stire the list int he column sturcture failed due to some obscure list corruption happening and was abandoned. Note also that user and unique ID's are needed.
With ext_curated we get and extra 1000 featuresets to scan for each column.
zmapWindowContainerFeatureSet is created by three different versions of the same code: normal, navigator and separator and these should be merged and moved into zmapWindowContainerFeatureSet.c
sequence config needs to filter through the many layers of app, mamager, control, view, window as a ZMapFeatureSequenceMap rather than as many arguments. Thi is needed to allow extra information such as 'dataset' to be accessable.
Here's a list of suspicious bits of code encountered while looking for something else
In zmpWindowCanvasItem.c zMapWindowCanvasItemGetBounds() looks like a cut & paste of zMapWindowCanvasItemGetFeature() directly above it including the explanatory comment. It's not called from anywhere.
zmapWindowFeatureShow.c appears to have some memory leaks - strings are strdup'd when creating a GUINotebook, but are they freed on Notebook destroy??
feature search with a wildcard featureset tries all possible rather than all existing featuresets: not very efficient.
window focus can crash on zmap shutdown due to a bad free (must be twice)