Persist file references

Currently, if a user needs to export to a file or select a folder they have to do it for every session. A session being the length a document is opened.

If they close XD, close the document or reload plugins they have to reselect the file reference.

Use Case
Betrand is writing a plugin to export vector graphics for his game, Vectobots. His game sits on one side of the screen and XD on the other.

Working with a lot of graphics he has numerous document windows open. In each one, he selects the file or folder to export to. Then he uses plugin panel to export on update events. He often has 20 designs open at a time and has to reselect the folder.

With the new persistent files feature, he has only had to choose the folder once and he hasn’t been prompted again.

Cross document events or the ability to use user identity management system is not likely going to be put on the roadmap this year, but I will put this in our backlog. Thank you!

I think the OP is just asking for a way to store a folder reference in a plugin’s private data, to persist across XD sessions.

1 Like

Yes. I had a user file it as a bug for my plugin. He said he has to keep selecting the export folder every time he works on a project. It’s only session by session but to him it seems like all the time.

My request is that once the user selects the folder they don’t have to select it again in the future. @kerrishotts mentioned there are operating systems reasons for this behavior.

We had talked about it on another forum but I don’t think there was a feature request made for it that users can vote on (I can’t find it).

@kerrishotts could you explain what you explained before about this? thanks :slight_smile:

So, on UWP, an app can request something like 1,000 persisted file handles. For a normal app, that’s a lot. But for an app that has plugins in it… it raises all sorts of questions:

  • How do we allocate persisted entries to plugins?
  • Is it first-come-first-serve?
  • Do we allocate a fixed amount (which could limit the # of pluginsinstallable)?
  • Could this be abused by one plugin to prevent other plugins from persisting handles?
  • What happens when we can’t get the handle – does the plugin just get an error, or does a picker appear – and if a picker does appear, is that surprising?

So it’s something we want to add (and on every platform aside from UWP, it’s no big deal), but we haven’t had the bandwidth to grapple with it on UWP yet.

That said, there are still other issues that do impact every OS:

  • What happens if the file referred to has moved?
  • … or is gone?
  • … or is on another volume?
  • … or the user no longer has permission to see it
  • etc.

Lots of things to think about :wink: (And we are…, so it’s not like we’re not going to do something about it – it’s just going to take us some time to reason through the edge cases.)