In the 5.6.0 update, we saw some updates to workspaces. It would be really useful to be able to query the name of the currently applied workspace, or even access a currently applied workspace object.
I’ve hit this as a limiting factor on a few occasions now, and it would be great to be able to be able to have such a query.
Could you tell me more about a likely use-case?
To a large extent in the way the app thinks internally, there is not a “current workspace” in the way you are implying.
In “use case” terms suppose I run a script that changes the workspace temporarily. I would like to be able to return to the original workspace at the end. That presupposes I know which workspace I started in.
Not a use case but “API hygiene”. If I can set the current workspace I ought to be able to retrieve same.
Here’s an example of the sorts of scenarios I encounter and wish that there was this sort of thing.
I have three web sites I might post information to via Drafts and I use a diferent workspace for each. I have a single action that I have a keyboard shortcut for that processes a draft ready for publishing and then pushes it to the site.
Whilst the triggered action can be set to pop-up a prompt to allow selection of the appropriate site to process and publish to, or a site identifier could be manualy added to a draft, being able to use the current workspace as the determining factor of what web site I’m working on a draft for would eliminate the need to use a menu.
With the latest revisions to include default action groups and extended keyboard rows I feel workspaces are moving beyond a pure filtering function and into a real workspace configuration function. As such, when I switch between workspaces, I feel it would beneficial to be able to have Drafts respond to that change in workspace without necessarily needing me to change my functional thinking.
If I’m using CMD+S to “Save” a file somewhere, the concept could well be transferable across workspaces, but the results of the process could be very different - e.g. saving stuff for Work might go to OneDrive, whereas saving stuff for home might go to Dropbox.
It is entirely a convenience thing for me, but as above, I feel this would be a good fit for using workspaces as a way to dynamically configure Drafts to the way you ar working at a particular time.
Does that make sense?
I like your first use case a lot. Whether the action that switches is “thin” - just grokking the workspace name and then driving a workspace-specific action. Or “thick” - with the logic for all the workspaces in one action.
While the structure of the app internally may not have a currently loaded workspace object, perhaps it has a notion of the last applied workspace?
The app can load a workspace and once loaded, the name of that workspace is visible within the app, above the folder names on the draft list. Therefore at some level within the application, that data must be held.
If there wasn’t such data being held, every time we viewed the draft list, we wouldn’t see the name of the workspace.
If I could access the name property in scripting, I could drive any subsequent tailored actions from that.
Workspace Specific New Draft Settings