Proposal : Add settings presets

Development
1

Hi everyone,

ParaView has a lot of settings and properties to configure how you want your data to be rendered, and it can be quite hard to find the perfect settings. Some of you might have written down a collection of settings that you have to set every time in order to get a specific style of rendering that suits your data well. This might work for one user, but this makes sharing settings between users inconvenient.

Another issue is that many users of ParaView might not know how to get a specific style of rendering (Realistic, CAD, …).

To solve this problem, I’d like to add settings presets to ParaView.

Settings preset would work like user default settings: you can save settings from a render view (View tab) or a proxy’s representation (Display tab) to re-apply them later (This could also work with filter properties, but it’s not our main goal here). The only difference for now would be that you can save multiple presets and name them.

I already have a working POC, but I want to open discussions about the UI part. We need two buttons: one to save current settings to a preset, and another one to apply a preset. We could reuse the save and restore application default settings values buttons, or we could add two new buttons. To show you what it looks like, I implemented both solutions.

On these two following screenshots, you can see that the save settings and restore settings buttons now have an arrow on the right. When clicking on it, multiple options are shown to apply a preset for the first one, and either overwrite an existing preset or create a new preset for the second button. Creating a new preset opens a dialog where the user can enter the preset name.

image
image630Ă—286 56.9 KB

image
image670Ă—344 72 KB

image
image823Ă—255 13.9 KB

On the two following screenshots, you can see two new “Apply preset” and “Save preset” buttons (that could just have an icon instead). Clicking on the buttons does nothing, but clicking on the arrow on the right shows options to apply or save to different presets.

image
image687Ă—295 65.3 KB

image
image687Ă—338 80.3 KB

I think the first solution is the best to avoid overloading the UI too much, but we could imagine many other possibilities such as adding a new panel to manage presets. Don’t hesitate to give your opinion of this UI change and maybe suggest something else !

A few presets could be included in the superbuild so that beginners could see ParaView’s capabilities. After implementing a first version of presets, I’d like to add support for more things such as textures, skyboxes and additional lights in the presets, and why not more UI to manage presets.

2

First version is much better in my opnion, no need to overload.

3

It’s a neat idea, but I’d love to survey some ParaView users to see how much they might use it.

@boonth @EthanStam @wascott @Kenneth_Moreland @insley @jfavre

IMO, the first option much better UI-wise. I think you’ll need a menu entry to restore to application presets, which is currently possible with the button

image
image118Ă—106 5.86 KB
.

Also, I think it’s useful to have a default preset that preserves the current custom defaults behavior - we don’t want to force users who have been using custom default settings to suddenly need to always pick a preset from a menu. So there should be a way to pick one of these presets as custom default, or have a special one that always applies when a custom preset isn’t selected.

4

This sounds like a pretty good idea. I generally don’t use the save settings feature, but converting it to presets makes sense, and maybe I would use it more if I didn’t have to worry about losing the default settings.

I agree that the “first option” is cleaner. However, one thing that I don’t care for is the dual nature of the buttons. What if the behavior was as follows.

The save button Screenshot 2026-09-03 at 10.05.23 AM never has a pull down menu. Instead, clicking on it brings up the “New Preset” dialog. The restore button Screenshot 2026-09-03 at 10.05.54 AM always brings up a pull down menu. The menu lists all available presents plus a special “Default” entry that is always at the top. That would make the behavior of the buttons easier to understand and also make them easier to click.

There are some downsides. This would remove the current feature of changing the default settings that are applied when an object is first created. That could be remediated by adding some widgets to the “New Preset” dialog that allows you to change the default instead of create a new present. Also, none of these solutions provide a means to remove presets. In any case, there could be another special item in the restore pulldown Screenshot 2026-09-03 at 10.05.54 AM that allows you to edit the presets.

5

I don’t have a strong feeling either way. From my experience, until I show users the four icons to allow settings to be saved, no one actually finds them.

The other thing I noticed is that row is already getting very full with the Display name (mesh type name). Maybe it’s time to move these icons to their own row? They aren’t very tall, thus don’t take up much space.

6

Yes, I was thinking of adding a “Preset manager” in the “Tools” menu to be able to add, rename and remove presets. That would leave only the important features on the main interface (save & restore).

7

Continuing the conversation from the MR stemming from this post. Let’s resolve whether “presets” and “defaults” are different things.

How they are the same

  • Both are sets of property values to apply to a source/representation/view in ParaView.
  • You can multiple of them - and arbitrary number of “presets”. For defaults, there are application defaults, user custom defaults, and site custom defaults.
  • Same JSON representation (implementation detail)

How they are different

  • Presets are only applied after proxy creation while defaults apply at proxy creation, except for a setting that specifies which “preset” to apply at creation.
  • User and site custom defaults and application defaults are baked into ParaView, an arbitrary number of “presets” can be created.

To me, they seem more alike than different, so in my mind this feature extends the idea of restoring defaults with the idea of presets. So to me the current user custom default sounds like just a special preset that is always there. But if you are thinking a preset is only something that is applied after creation (except for a special one you designate in the settings), then conceptually a separation makes sense. So before we go on, are custom defaults just presets, or are they to be a truly distinct concept?

8

I do agree that custom defaults are just presets. If we take this the other way around, presets are just a way to store multiple custom defaults. So to me these are the same thing, but I think user custom defaults should definitely be treated as a “special” preset in the UI (can’t be deleted, first in the list, etc)

After merging a first version of the presets, I plan to add support for more “settings” into the preset logic (and into the custom defaults settings as they are using the same implementation), such as additional lights or camera position. I don’t think this would make the presets it’s own thing compared to custom defaults.

9

I agree that there are differences between custom defaults and presets, but I feel there is benefit to both to combine these features and treat the default as a special preset. It makes it easier to manage the default, can make the default accessible even if not customized, and allows you to re-apply the default state without recreating a proxy.

10

This is slightly orthogonal but related to this discussion I believe. One of the current issues with “Save Current Settings Values as Default” in the Properties sub tab is that there is no granularity. User may want to make IOSS reader settings sticky (such as the infamous “Read All Files To Determine Structure”, but they really don’t want to also have ParaView remember set variables. Maybe this refactor could deal with that problem also?

11

Actually, you can save a default value for a single property - Ctrl-Click on the label of a property and select “Use as Default”. I am embarrassed to say that it is not documented at docs.paraview.org, but it is possible.

12

So if custom defaults are just special presets, then I believe we should just have user custom defaults and application defaults at the top of the apply preset button dropdown menu, followed by the whole list of presets, right ?

13

That makes sense to me.

14

I think a split button should always do something when it is clicked in the button region whereas clicking the drop-down arrow followed by a selection should both execute the menu item and make it the new default action (i.e. change the button icon so that the user knows what the click action actually means). Is that the intention in the first proposal? :thinking:

15

Well, this was not really my intention because that would mean having one unique icon for each preset + user customs. But instead what I can do is keep these two buttons like they were before, without the arrow on the side, but making them always open their menu when clicked, without executing any default action. This way, we can keep the original icons and users will always be sure of what preset/default they are applying. The only downside I see with this approach is that we would need two clicks to reset to application defaults (vs 1 before), unless if you keep your left click pressed and release it on the menu item that you want to execute.

16

In that case I would suggest that you have three options.

a) Introduce two new split buttons with text labels, which function as I described previously, for saving/restoring the selected preset and possibly two new appropriate icons; whatever they may be.

b) introduce one new drop-down button with text labels for selecting a preset placed beside two new save/restore “preset” buttons and possibly two new icons to suit.

c) convert the existing save/restore buttons into split buttons with text labels, which function as I described previously, but retain the existing icons and treat the original behaviour as if it is just a special “preset” as suggested by others.

The last option keeps the clutter to a minimum and the original save/restore “default” options could possibly be indicated by a modified icon with an embedded asterisk or maybe a different background colour for example as well a suitable text label. In that case there would be little change from the user’s perspective if they don’t create their own presets.