MantisBT - ParaView
View Issue Details
0015337ParaView(No Category)public2015-02-20 20:472015-09-06 12:17
Alan Scott 
Utkarsh Ayachit 
normalminorhave not tried
closedfixed 
4.3 
4.44.4 
Sandia
incorrect functionality
0015337: Save/ Restore current settings as default - Properties is broken
There are at least two issues with Save current settings values as default for Properties. Bigger picture, I am not sure if we want to even be able to save settings for properties. But, assuming this code is here for some purpose and some user, here are the two bugs, and how to replicate them.

* PV 4.3.1, local server, Linux.
* load can.exo. All vars on. Now, turn VEL off. In the blocks section, turn off the second block. Apply.
* Save current settings values as default (for Properties).
* Reset session. Reload can.exo. Apply. Notice that the behavior I would expect happens - we have not loaded the second block or VEL.
* Click Restore application default settings values.
<<bug>> Nothing happens. I assume this is a bug.
* Reset session. Reload can.exo. Apply.
<<bug>> We still have not loaded the second block or VEL. So, Restore does not work. It needs to be fixed.

* Reset session.
* Load disk_out_ref.exo. Apply.
<<bug>> Note that we still have the variables displayed in the Properties tab from can.exo!
-- Seems to me that a saved current settings value needs to be tied to a specific dataset. Further, I don't think we want more than one dataset, or the underlying json file is going to blow up to a huge size.

-- Higher level question - is this how we want to allow users to default variables and blocks on/off? Isn't a saved state a better solution? (By the way, was this implemented for one of my users? I don't remember.)
No tags attached.
Issue History
2015-02-20 20:47Alan ScottNew Issue
2015-02-20 21:32Alan ScottTarget Version => 4.4
2015-06-22 11:33Cory QuammenAssigned To => Cory Quammen
2015-07-01 08:51Utkarsh AyachitNote Added: 0034643
2015-07-07 20:59Alan ScottNote Added: 0034683
2015-07-08 13:25Utkarsh AyachitNote Added: 0034702
2015-07-08 16:36Utkarsh AyachitStatusbacklog => todo
2015-07-09 11:01Utkarsh AyachitNote Added: 0034718
2015-07-09 11:09Utkarsh AyachitAssigned ToCory Quammen => Utkarsh Ayachit
2015-07-09 11:09Utkarsh AyachitStatustodo => active development
2015-07-09 11:39Utkarsh AyachitNote Added: 0034721
2015-07-09 11:39Utkarsh AyachitStatusactive development => gatekeeper review
2015-07-09 11:39Utkarsh AyachitFixed in Version => git-next
2015-07-09 11:39Utkarsh AyachitResolutionopen => fixed
2015-07-13 12:42Utkarsh AyachitNote Added: 0034766
2015-07-13 12:42Utkarsh AyachitStatusgatekeeper review => customer review
2015-07-13 12:42Utkarsh AyachitFixed in Versiongit-next => git-master
2015-07-27 20:46Alan ScottNote Added: 0034838
2015-07-27 20:46Alan ScottStatuscustomer review => closed
2015-09-06 12:17Utkarsh AyachitFixed in Versiongit-master => 4.4

Notes
(0034643)
Utkarsh Ayachit   
2015-07-01 08:51   
Alan,

The save/restore defaults doesn't work for properties that get their values at run times e.g. array selections. It's designed more for things like setting the Font Size for Scalar Bar, for example. But you bring up a good point, the user doesn't know this when he looks at the UI. I wonder how we can show that.

The way this is different from state is that, a "default" get applied every time the user creates that particular type of source. e.g. create a sphere, change its Phi Resolution, Apply , Save as default then quit. Now restart ParaView. Everytime you create a Sphere, it'll get the default value you specified for Phi Resolution.

FYI:
http://www.kitware.com/blog/home/post/702 [^]
(0034683)
Alan Scott   
2015-07-07 20:59   
Note that the test I provided above DOES get properties at run time - i.e., variables. This is the problem.
(0034702)
Utkarsh Ayachit   
2015-07-08 13:25   
It is expected to get properties like "Variables" at run time. As I mentioned, the save default mechanism **does not** save properties that are "dynamic" or data-dependent.
(0034718)
Utkarsh Ayachit   
2015-07-09 11:01   
Oops..I was being daft :o). Alan's right. This is a bug.
(0034721)
Utkarsh Ayachit   
2015-07-09 11:39   
Merge request:
https://gitlab.kitware.com/paraview/paraview/merge_requests/204 [^]
(0034766)
Utkarsh Ayachit   
2015-07-13 12:42   
merged in master
(0034838)
Alan Scott   
2015-07-27 20:46   
Tested local server, Linux, master.