Persisting state of UI

[Jakob Kousholt]

Hey Folks,

I'd love to get your approach to make state persist of your UI. Let's say I have a custom-built UI and for the majority of the time, the user input in the UI will be the same per scene. So next time they load up their scene and open my UI the settings they entered the first time around should persist. What is your approach? Do you create some arbitrary node in the scene which holds the information, or what would be considered a good approach? Looking forward to your approach, thanks!

Jake

[Chad Fox]

I usually store user saved presets as json files that can repopulate the UI when the preset is selected. You could also save current state on UI close and on UI show have it look for the saved state to set the initial UI state.

I would opt for this over a software specific node that only works in, say Maya. 

Interested to hear others thoughts as well. 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAEKd6baxEMb21GugKE7cWb0F38aSBR4c1z82UEWm-7sxq8j4Lw%40mail.gmail.com.

[Justin Israel]

On Sun, Aug 18, 2019, 4:41 AM Jakob Kousholt <jak...@gmail.com> wrote:

Hey Folks,

I'd love to get your approach to make state persist of your UI. Let's say I have a custom-built UI and for the majority of the time, the user input in the UI will be the same per scene. So next time they load up their scene and open my UI the settings they entered the first time around should persist. What is your approach? Do you create some arbitrary node in the scene which holds the information, or what would be considered a good approach? Looking forward to your approach, thanks!

Is it Maya native UI or Qt? 

For Maya native UI I had always thought that an accepted approach was to store the UI prefs in Maya OptionVars? If they are really complex settings then I guess you could go with Chad's suggestion of storing a json prefs file. 

For Qt, it already provides a QSettings concept which knows where to store, and retrieves it for you based on app and organisation name. Even if you aren't using Qt for your UI, technically you could use QSettings from PySide to manage your prefs if you don't want to deal with the filesystem details. 

[Jakob Kousholt]

Thanks, Guys! 

I wasn't aware of either QSettings or OptionVars, so I will definitely look into those.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3JZ9FVYusT59RbN6T%2B1RB95Ta%3DN7NjaH_p0oSXdtmN0Q%40mail.gmail.com.

[Chad Fox]

Thanks as well for mentioning QSettings. I've not read about this before and will take a look!

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAEKd6bbrAm%3D-DaQ_zsROOSULqR7FpgmE2o7OhgQOSybECmJzbg%40mail.gmail.com.

[Russell Pearsall]

One gotcha with Qsettings is that it will cast everything to a str before storing it. So if you pass 3.14 for some setting, you’ll get “3.14” back.

For that reason, I generally subclass qsettings to pickle/unpickle the values before passing it to super() to store the value

[Justin Israel]

On Sun, Aug 18, 2019 at 3:08 PM Russell Pearsall <robo...@gmail.com> wrote:

One gotcha with Qsettings is that it will cast everything to a str before storing it. So if you pass 3.14 for some setting, you’ll get “3.14” back.

For that reason, I generally subclass qsettings to pickle/unpickle the values before passing it to super() to store the value

Which version of the Qt bindings have you found this to be true?  In PySide2 it seems to handle python object types just fine, and it retains a float type.

I remember PyQt used to have issues when it encoded a bool, and it would store it as an int. So you would have to cast it back later.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/5e0e209c-d07a-4f86-9f97-cf3c0a83df65%40googlegroups.com.

[Russell Pearsall]

I noticed the issue when developing in pyqt, but have not tested it in pyside2. Thanks for the heads up, it would be great if that was addressed!

On Saturday, August 17, 2019 at 8:28:01 PM UTC-7, Justin Israel wrote:

On Sun, Aug 18, 2019 at 3:08 PM Russell Pearsall <robo...@gmail.com> wrote:

One gotcha with Qsettings is that it will cast everything to a str before storing it. So if you pass 3.14 for some setting, you’ll get “3.14” back.

For that reason, I generally subclass qsettings to pickle/unpickle the values before passing it to super() to store the value

Which version of the Qt bindings have you found this to be true?  In PySide2 it seems to handle python object types just fine, and it retains a float type.

I remember PyQt used to have issues when it encoded a bool, and it would store it as an int. So you would have to cast it back later.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.