Search should search all labels - e.g. GID and NAME, even if GID is set as the row labels

[Robert Leach]

Might be good if this could be an option if not the default behavior.

[Christopher Keil]

This has always been the case, has it not?

[Robert Leach]

What I mean is, if the user has a GID label set and a NAME label set, and a "WHATEVER" label set for rows, we should search them even if they are not set to display as the row labels. I think we could also provide this data in tooltips or when we copy/export, or a whole series of functions. Perhaps we could even allow different label types to be concatenated? Maybe that's too crazy. But definitely in the search, if a user expects a label to be present but it's not set to be among the labels by default.

I even had an idea of having a convenient way to cycle through the label types in the interface (like a button below the rows and to the right of the columns.

I'll edit the title & description to make it less ambiguous.

[Robert Leach]

Given that issue #248 will add the ability to easily select which label types to search and that this fix does not yet have the ability to make such a selection, I'm pondering how to decide when to search all label types (always, when there's no other result, etc.).

Our search currently behaves like this: if there's a full/perfect match, only that match is highlighted. If there are no matches, all results where the search term is a substring are highlighted. We could use the same logic for other label types, but I'm not 100% sure that that would be the best idea.

Take this use case example: if the user has a numeric GID and we always search all label types, then a search for '1' would return ALL rows because '1' matches all GWEIGHT labels.

Take this other use case: If the user has 2 label types, but the one in the display has no matches to the search term, but there are matches in the label type which is not visible, the user would see highlighted results that do not appear to match their search term - which could degrade user trust in the tool.

Perhaps such concerns however are minor. Consider this: the app currently does not remember the selection of the label type to view when a file is re-opened. Thus, they have to manually adjust the label selection in the settings every time - though they may not know that they need to do this and they may not recognize that the labels displayed are not the ones they had previously selected. When they perform the search, since other types are not searched, they would not find what they're looking for and thereby, lose trust in the tool because they know the result should be there...

So the concerns about searching all label types may be rarer than the repeated benefit of always searching all types.

That said, perhaps we should use a logic similar to the wildcard search: if we find a perfect match in the visible label type, return only it. If nothing is found, search the other label types. Using this logic, we mitigate the first use case example. However, the second one is still a problem.

To mitigate the second use case example, we could give a visual cue that something is different about the results. We could show the matching labels in the dropdown list in gray text and/or even change the search term text gray. OR, perhaps it's possible to prepend the result with the alternate label type name (though I don;t think that would be possible - I will look into it).

If we assume that people know what they're looking for and are somewhat familiar with their data, then it shouldn't be too big of an issue. Besides, the alternate label type is slated to be visible in other ways too.

I will make sure that this code will lay the groundwork for supporting issue #248.

[Robert Leach]

I've got this working. We may decide to tweak the behavior. BTW, there seemed to be some data members in HeaderFinderBox that were copies of the contents of other data members (labelArray in HeaderInfo is basically copied into 2 other variables which are used in searching and in populating the combobox). I kept one of the copied data members. In fact, I modified one to hold the extra labels, but I'm not sure why we're copying this data instead of using it directly from HeaderInfo. So I may decide to skip the middle man in car anyone has any good reason for the copy.

[Robert Leach]

Resolved on branch 'issue206'.

[Robert Leach]

Merged with Master.

[Robert Leach]

Removing milestone: Search (automated comment)