Choosing start tab
Closed this issue · 7 comments
Goal
To enable developers to choose which tab their users should start in.
Motivation
"Artist Page"
"Overview Page"
Advanced users, that would like to see the "advanced-tab" to begin with.
Implementation
It could be an argument passed to pyblish-lite.show(). but that breaks the standardization across the guis. So maybe an environment variable PYBLISH_LITE_PAGE=overview?
Good idea.
Both QML and Lite needs configurable defaults and configuration options at all. The way I've imagined it is for a .pyblish-lite configuration file to be generated and/or read at startup with the configuration. In that way, users can modify this at will, and admins can install a default one.
We could do environment variables instead, it would remain similar to other options throughout Pyblish and is powerful in its own right. My only concern would be when options grow and we start to pollute the environment with options. I'm expecting configuration to blossom at some point however and would accept a new standard for this once we get to that.
Up to you, I'm up for it!
Maybe an environment variable to a configuration file?
When managing people in a studio, I don't fancy configuring each machine individually, so it'll be nicer to point to a shared configuration file.
Ah, this depends on what kind of information we store there; temporal or persistent.
For example, one user may want to store a particular filter in the main overview, and have the window remember it's size and position each time it opens. But you as an admin may want the default start-up dialog to be on the Overview, and no the Artist Page.
Temporal settings should probably not be global, whereas persistent once should probably not reside in a user's home directory.
Maybe let's focus this issue on persistent settings, in which case environment variables could work, or an environment variable to a file, like userSetup.py of Maya.
Have a feel for each, and PR when you're comfortable.
As an aside, one option may be to simply remember the last-open tab and restore it next time a user opens the dialog. Then we won't need persistent settings, just temporal ones.
Remembering the last tab would do for my situation.
If in the future the settings need a shared overwrite the process could be additive, so only the one setting needed studio wide is overwritten and the rest is taken from the local machine.
What format are you thinking for the configuration? Json, python files?
Python, json, yaml, toml, ini, xml, sqlite, windows registry, bash scripts. Anything. You pick.
Whichever you try, we can always iterate. Think about dependencies, human readableness (and whether it is needed), performance (if relevant), whether it needs concurrent read/write access, why and when etc.
Implemented with this; #65