Currently the color table tag filtering selection is only loaded once the color table window has been opened. Is this a bug?

[JustinPrivitera]

We made the choice to always enable color table tagging so that when a user looks at a list of color tables, the list is much shorter. If they want to customize what is on that list, they can play with the color table manager. However, in order to actually make the tag filtering selection register and update all of the color table buttons, the color table window needs to be opened, since it houses all of the tag management and setup. This means that if a user opens visit and goes to choose a color table without first opening the color table window, they will be presented with all the color tables.

On the one hand, this seems wrong. Surely if we want tag filtering to always be enabled, then tag filtering should be something that lives outside the scope of the color table window and affects all buttons whether or not the color table window has been opened.

On the other hand, it kind of makes sense for things to be this way. If you don't care about managing the list of color tables, you won't open the color table window, and probably don't mind seeing all the color tables as choices. Then if you want to pare that down, you can open the window.

I personally feel that the current behavior is wrong, and tag filtering should exist at a larger scope. I could use some guidance on implementing that successfully. But first, what do @visit-dav/visit-developers think? Is this a bug, or is it acceptable behavior?

[biagas]

Are you recommending having the 'filtering' logic be external to the ColorTableWindow, and be accessible by individual ColorTableButtons so that on 'Mouse Down' or similar event (for the button), the filtering logic is called which may make the color tables available for that button smaller? But the actual controls that can affect the filtering still live in ColorTableWindow ?

I guess I am unclear on how the filtered list is accessed by the color table buttons in the first place.

[JustinPrivitera]

That is what I am recommending, yes.

Currently, the color table window tells the color table attributes which color tables are currently in the filtering selection, and color table buttons get the information from the color table attributes and go from there.

[biagas]

Is the filtering expensive? Should it be done on-the-fly by the color table attributes whenever the list is requested? I assume more info would need to be stored in the atts to make this possible (and made private/not visible when possible).

Are users' custom tables available in a Color table button if the Color Table window has never been opened? If they are, then perhaps a similar code path can be taken on startup to provide the initial filtering ?

[JustinPrivitera]

The filtering itself involves a triple for-loop. That said, the number of color tables and tags is typically very small, and causing the filtering to be recalculated is very fast for the color table manager. We would probably need to have the list of tags live inside of the color table attributes, which may or may not be easy.

Are users' custom tables available in a Color table button if the Color Table window has never been opened? If they are, then perhaps a similar code path can be taken on startup to provide the initial filtering ?

Yes they are. At this point I don't understand why though. There is a possibility that that would hold the key to making this work in a simpler way.

[biagas]

Yes they are. At this point I don't understand why though. There is a possibility that that would hold the key to making this work in a simpler way.
Here's where user tables are imported:

visit/src/viewer/core/ViewerStateManager.C

Lines 286 to 288 in 23a936d

	// Import external color tables.
	if(!GetViewerProperties()->GetNoConfig())
	avtColorTables::Instance()->ImportColorTables();

avtColorTables::ImportColorTables turns around and calls ColorTableManager::ImportColorTables

So it seems like a good bet that the filtering mechanism could be called after the import.

[JustinPrivitera]

Ahhh. Thanks for pointing me in the right direction.

[markcmiller86]

If the number of color tables one is confronted with when clicking on the color table selection button for a given plot is one the order of one page worth (or screen height's worth), then the current behavior would probably be tolerable.

However, the number of color tables one is confronted with in that situation is currently many pages (or screen height's worth) and so I don't think the current behavior is tolerable.

I also worry that as currently implemented, tag filtering is kinda sorta a side-effect of opening the color table manager.

I have the vague recollection that when we started down the path of tags and filters, there were a handful of color tables that were assigned the default or standard tag. And, at the time, I kinda sorta thought that would mean that if no user had opened the color table manager, then only the tables in the default or standard set would be presented to them when selecting a color table from a plot.

[JustinPrivitera]

If the number of color tables one is confronted with when clicking on the color table selection button for a given plot is one the order of one page worth (or screen height's worth), then the current behavior would probably be tolerable.

At 1440p the current list of color tables is forced to be 3 columns, where two columns take up the entire vertical length of the screen and the last column takes up half. So, not tolerable.

[JustinPrivitera]

So, echoing what Mark said, if the user hasn't opened the color table window then the user would only see tables in the Default set.

The wrinkle here is that if a user is restoring a session or has saved settings that have a different color table tag filtering selection, their tag choices will not be respected until they open the color table window. So it is not enough to simply force the color table buttons to only show Default and User-Defined color tables the first time they are used; they need to know what tags are enabled.

[brugger1]

@JustinPrivitera You are correct, if the user has saved settings or is restoring a session, then the filtering should use what would appear in the color table window.

[markcmiller86]

So it is not enough to simply force the color table buttons to only show Default and User-Defined color tables the first time they are used; they need to know what tags are enabled.

Though I think I get your meaning here, the implementation that I would have expected to follow from this would be one where VisIt behaves as though tag filtering is always in use. The only question is what the currently active (probably not using correct terminology here) tag(s) are. In the absence of anything the user has done to explicitly set that, I think the active tag(s) should be just the Default (or was it Standard).

Now, I guess a user may have saved session or settings with a different tag filtering in two ways...one is saved content that pre-dates the introduction of tag filtering. In that case, act as though saved tag filtering was set to Default. Otherwise, then whatever the tag filtering of the saved session or settings is should take effect.

This may all mean that immediately upon startup (not just when the color table manager is opened for the first time) and before settings (or session if applicable) is read, VisIt has tag filtering set to Default. Then, reading of settings or session may override that. Opening of color table manager starts with whatever tag filtering setting has already been set to. Of course, I am not in the GUI code to know for sure if that sequence of operations actually jives. But, it seems plausible.

[JustinPrivitera]

Though I think I get your meaning here, the implementation that I would have expected to follow from this would be one where VisIt behaves as though tag filtering is always in use.

The implementation that I went with originally grew naturally beyond the scope of the color table window, and I think I am now grappling with limitations based on choices I made long before I understood really what was happening. As it stands, the color table window behaves as though tag filtering is always in use, and the rest of VisIt must play catch up once the color table window figures out everything it needs to do to get set up.

The only question is what the currently active (probably not using correct terminology here) tag(s) are.

Actually, that's the terminology I used internally. Tags that are enabled are "active". This gets confusing quickly however, as color tables that are present in the current filtering selection are also "active". My bad. 😅

In the absence of anything the user has done to explicitly set that, I think the active tag(s) should be just the Default (or was it Standard).
Now, I guess a user may have saved session or settings with a different tag filtering in two ways...one is saved content that pre-dates the introduction of tag filtering. In that case, act as though saved tag filtering was set to Default. Otherwise, then whatever the tag filtering of the saved session or settings is should take effect.

Agreed. This is already the case, albeit only once the color table window has been opened and run all of the initialization code that handles tags.

This may all mean that immediately upon startup (not just when the color table manager is opened for the first time) and before settings (or session if applicable) is read, VisIt has tag filtering set to Default. Then, reading of settings or session may override that. Opening of color table manager starts with whatever tag filtering setting has already been set to. Of course, I am not in the GUI code to know for sure if that sequence of operations actually jives. But, it seems plausible.

I think the big takeaway I am getting from hearing everyone's views is that yes, the way things currently work is problematic, and that the answer is to make sure that tags are handled somewhere on startup instead of only once the color table window is opened. I'll work on fixing soon. 👍

[JustinPrivitera]

Opened #18894 to capture this issue; will be fixed in an upcoming PR.