Request for personal-files for OpenRocket

The OpenRocket community would like to deliver OpenRocket as a snap package. OpenRocket is a java based application that has an existing user base which has been designing their own model and high powered rockets. In considering the user experience, we would like it to “just work” regardless of whether users are running the jar file, the installed debian package, or the snap.

The OpenRocket application access two hidden directories within the user’s home directory:

  • $HOME/.java/.userPrefs/OpenRocket - used by the Java Preferences API for storing user preferences on UI settings and application behavior
  • $HOME/.openrocket - used for storing application specific data (which includes a model rocket motor database, parts database, etc).

To facilitate a seamless transition for our user base, we request that the snapcraft store allows for the personal-files interface. The snapcraft.yaml file for the application narrowly scopes the request to only be what is required for the application:

plugs:
  dot-java-user-prefs-openrocket:
    interface: personal-files
    read:
      - $HOME/.java/.userPrefs/OpenRocket
    write:
      - $HOME/.java/.userPrefs/OpenRocket
  dot-openrocket-db:
    interface: personal-files
    read:
      - $HOME/.openrocket
    write:
      - $HOME/.openrocket

The snap itself has not yet been published as it requires this approval before the store will accept the upload been published to the edge channel without these interfaces to facilitate any review. An account has been registered for OpenRocket to publish the resultant snaps under the official OpenRocket account.

Additionally, we would request that since the OpenRocket application uses appropriately named resources scoped to the application specifically that the interfaces be auto connected upon installation.

We are happy to make any necessary changes to facilitate the enablement and auto-connection of the personal-files interface for the OpenRocket snap package.

i’m not a reviewer, but i’m pretty sure they will ask you to somehow have “openrocket” in that interface name since it isnt just generically granting access to $HOME/.java/.userPrefs

Ah, fair point. I’ll make a change to further clarify this to dot-java-user-prefs-openrocket.

Done.

1 Like

@reviewers any feedback on this request?

+1 from me, access to specific personal files tied to OpenRocket makes sense for the necessary functionality of the app.

@wolsen - write access implies read so there is no need to list both - also can you rename the instance for ~/.openrocket to just dot-openrocket since this is clearer - so you can simplify the plugs to:

plugs:
  dot-java-user-prefs-openrocket:
    interface: personal-files
    write:
      - $HOME/.java/.userPrefs/OpenRocket
  dot-openrocket:
    interface: personal-files
    write:
      - $HOME/.openrocket

+1 from me for both since openrocker is the clear owner of both of these paths.

+2 votes for, 0 votes against, this is now live (once a new snap with the above changes has been uploaded it should pass automated review).