New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support sandbox bookmarks in MAS build #4637

Closed
positlabs opened this Issue Feb 29, 2016 · 12 comments

Comments

Projects
None yet
10 participants
@positlabs

positlabs commented Feb 29, 2016

  • Electron version: 0.35.6
  • Operating system: OSX 10.11

Seems like app-scoped and document-scoped bookmarks are currently unsupported by Electron. This is a pretty huge feature for usability. E.g. not needing to re-select an output directory every time the user restarts the app.

There's a thread about this over at electron-userland/electron-packager#271

I'm unfamiliar with truly native dev, but here's an article about implementation

And Apple docs on bookmarks

@jasonhinkle

This comment has been minimized.

Show comment
Hide comment
@jasonhinkle

jasonhinkle Mar 2, 2016

+1 , otherwise all mac app store apps are limited to using the Downloads, Movies, Music or Pictures folders for storage, which don't always make sense for the app.

jasonhinkle commented Mar 2, 2016

+1 , otherwise all mac app store apps are limited to using the Downloads, Movies, Music or Pictures folders for storage, which don't always make sense for the app.

@jdp

This comment has been minimized.

Show comment
Hide comment
@jdp

jdp Mar 8, 2016

Somewhat related, would it be possible to have app.getPath return a path compatible with App Sandbox when appropriate? Sandboxed apps don't have access to ~/Library/Application Support (but they do have access to ~/Library/Containers/<bundle_id>/Data/Library/Application Support/<app_name>/), and I'm not sure where I should start to store the files used for persisting app state across restarts in the meantime.

jdp commented Mar 8, 2016

Somewhat related, would it be possible to have app.getPath return a path compatible with App Sandbox when appropriate? Sandboxed apps don't have access to ~/Library/Application Support (but they do have access to ~/Library/Containers/<bundle_id>/Data/Library/Application Support/<app_name>/), and I'm not sure where I should start to store the files used for persisting app state across restarts in the meantime.

@positlabs

This comment has been minimized.

Show comment
Hide comment
@positlabs

positlabs Mar 8, 2016

@jdp persisting app state shouldn't be a problem. See my output for various app.getPath arguments in mas builds. It seems like what you are asking for is already implemented.

screen shot 2016-03-08 at 1 39 02 pm

positlabs commented Mar 8, 2016

@jdp persisting app state shouldn't be a problem. See my output for various app.getPath arguments in mas builds. It seems like what you are asking for is already implemented.

screen shot 2016-03-08 at 1 39 02 pm

@jdp

This comment has been minimized.

Show comment
Hide comment
@jdp

jdp Mar 9, 2016

You're right, my problem was that I was using tmp, which I didn't have permissions for. app.getPath returns an appropriate container path.

jdp commented Mar 9, 2016

You're right, my problem was that I was using tmp, which I didn't have permissions for. app.getPath returns an appropriate container path.

@Maay

This comment has been minimized.

Show comment
Hide comment
@Maay

Maay commented Apr 4, 2016

+1

@fuermosi777

This comment has been minimized.

Show comment
Hide comment
@fuermosi777

fuermosi777 Sep 13, 2016

Any updates?

fuermosi777 commented Sep 13, 2016

Any updates?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 15, 2017

Wondering if this has been solved in any way?
I'm making a writing app (similar to Atom) which has a treeview for open folders, and it remembers open files on startup - but because of the Sandbox every time the app starts it's denied access to all of these files and folders, and thus the user must manually specify them again using the open or save dialogs.

Having app-scoped bookmarks would solve this problem, is there any way to do so with the current version of Electron?

ghost commented Feb 15, 2017

Wondering if this has been solved in any way?
I'm making a writing app (similar to Atom) which has a treeview for open folders, and it remembers open files on startup - but because of the Sandbox every time the app starts it's denied access to all of these files and folders, and thus the user must manually specify them again using the open or save dialogs.

Having app-scoped bookmarks would solve this problem, is there any way to do so with the current version of Electron?

@fuermosi777

This comment has been minimized.

Show comment
Hide comment
@fuermosi777

fuermosi777 Feb 28, 2017

just curious why this issue hasn't attract enough attention as it is such an important one

fuermosi777 commented Feb 28, 2017

just curious why this issue hasn't attract enough attention as it is such an important one

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 28, 2017

@fuermosi777 I don't know, it's definitely essential for some mas apps!

In the meantime I've written a module electron-bookmarks that has support for app-scoped bookmarks only. I'm planning on adding support for document-scoped bookmarks but it seems a little tricky.

Please note however, that this module uses nodobjc to bridge to the Objective-C runtime.

EDIT: Just to let everyone know that I have submitted apps to the Mac App Store which use this module, and they have passed the Review Process 👍
I would however, like to add this in to the electron core - since it would save a lot of size and be more robust (the deps req. for the module are rather heavy, and a little hacky).


My implementation of the bookmarks API is rudimentary, and rather hacky considering it's all done through bridging. Apple provides APIs in the CoreFoundation frameworks which are easily accessible in C or C++ (what chromium and electron are mainly written in) which would be extremely preferred to accessing the Objective-C runtime through node bridging.

ghost commented Feb 28, 2017

@fuermosi777 I don't know, it's definitely essential for some mas apps!

In the meantime I've written a module electron-bookmarks that has support for app-scoped bookmarks only. I'm planning on adding support for document-scoped bookmarks but it seems a little tricky.

Please note however, that this module uses nodobjc to bridge to the Objective-C runtime.

EDIT: Just to let everyone know that I have submitted apps to the Mac App Store which use this module, and they have passed the Review Process 👍
I would however, like to add this in to the electron core - since it would save a lot of size and be more robust (the deps req. for the module are rather heavy, and a little hacky).


My implementation of the bookmarks API is rudimentary, and rather hacky considering it's all done through bridging. Apple provides APIs in the CoreFoundation frameworks which are easily accessible in C or C++ (what chromium and electron are mainly written in) which would be extremely preferred to accessing the Objective-C runtime through node bridging.

@hackjutsu

This comment has been minimized.

Show comment
Hide comment
@hackjutsu

hackjutsu commented Mar 1, 2017

+1

@goodhyun

This comment has been minimized.

Show comment
Hide comment
@goodhyun

goodhyun Mar 12, 2017

@callodacity
Thanks for the module, but I'm having an issue here
https://gitlab.com/callodacity/electron-bookmarks/issues/1

any idea?

goodhyun commented Mar 12, 2017

@callodacity
Thanks for the module, but I'm having an issue here
https://gitlab.com/callodacity/electron-bookmarks/issues/1

any idea?

@matthieuh

This comment has been minimized.

Show comment
Hide comment
@matthieuh

matthieuh commented Aug 31, 2017

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment