View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0015337 | ParaView | (No Category) | public | 2015-02-20 20:47 | 2015-09-06 12:17 | ||||
Reporter | Alan Scott | ||||||||
Assigned To | Utkarsh Ayachit | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 4.3 | ||||||||
Target Version | 4.4 | Fixed in Version | 4.4 | ||||||
Summary | 0015337: Save/ Restore current settings as default - Properties is broken | ||||||||
Description | 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.) | ||||||||
Tags | No tags attached. | ||||||||
Project | Sandia | ||||||||
Topic Name | |||||||||
Type | incorrect functionality | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0034643) Utkarsh Ayachit (administrator) 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 (manager) 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 (administrator) 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 (administrator) 2015-07-09 11:01 |
Oops..I was being daft :o). Alan's right. This is a bug. |
(0034721) Utkarsh Ayachit (administrator) 2015-07-09 11:39 |
Merge request: https://gitlab.kitware.com/paraview/paraview/merge_requests/204 [^] |
(0034766) Utkarsh Ayachit (administrator) 2015-07-13 12:42 |
merged in master |
(0034838) Alan Scott (manager) 2015-07-27 20:46 |
Tested local server, Linux, master. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2015-02-20 20:47 | Alan Scott | New Issue | |
2015-02-20 21:32 | Alan Scott | Target Version | => 4.4 |
2015-06-22 11:33 | Cory Quammen | Assigned To | => Cory Quammen |
2015-07-01 08:51 | Utkarsh Ayachit | Note Added: 0034643 | |
2015-07-07 20:59 | Alan Scott | Note Added: 0034683 | |
2015-07-08 13:25 | Utkarsh Ayachit | Note Added: 0034702 | |
2015-07-08 16:36 | Utkarsh Ayachit | Status | backlog => todo |
2015-07-09 11:01 | Utkarsh Ayachit | Note Added: 0034718 | |
2015-07-09 11:09 | Utkarsh Ayachit | Assigned To | Cory Quammen => Utkarsh Ayachit |
2015-07-09 11:09 | Utkarsh Ayachit | Status | todo => active development |
2015-07-09 11:39 | Utkarsh Ayachit | Note Added: 0034721 | |
2015-07-09 11:39 | Utkarsh Ayachit | Status | active development => gatekeeper review |
2015-07-09 11:39 | Utkarsh Ayachit | Fixed in Version | => git-next |
2015-07-09 11:39 | Utkarsh Ayachit | Resolution | open => fixed |
2015-07-13 12:42 | Utkarsh Ayachit | Note Added: 0034766 | |
2015-07-13 12:42 | Utkarsh Ayachit | Status | gatekeeper review => customer review |
2015-07-13 12:42 | Utkarsh Ayachit | Fixed in Version | git-next => git-master |
2015-07-27 20:46 | Alan Scott | Note Added: 0034838 | |
2015-07-27 20:46 | Alan Scott | Status | customer review => closed |
2015-09-06 12:17 | Utkarsh Ayachit | Fixed in Version | git-master => 4.4 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |