Skip to content
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

localstorage for remembering settings #16

Open
4 of 11 tasks
edemaine opened this issue May 25, 2020 · 3 comments
Open
4 of 11 tasks

localstorage for remembering settings #16

edemaine opened this issue May 25, 2020 · 3 comments
Labels
priority High-priority because of requests or importance

Comments

@edemaine
Copy link
Owner

edemaine commented May 25, 2020

  • I think it'd be nice to remember your line thickness, text size, pen color, fill color, grid snapping between sessions in localstorage. I think this should be per room? Could also choose to set them to default on the entire machine, maybe via right click/double click for options menu.

    • Line thickness
    • Text size
    • Pen color
    • Fill color
    • Grid snapping
  • Possibly even more useful is to keep track of the list of room IDs that this machine has visited (with I guess the option to delete some). That list would be really handy, especially before but even with user accounts (User accounts #4).

  • Could also store remoteId, which would preserve your ID across reloads (so less likely to get a stale cursor), though this makes things slightly less private. Maybe only store when name is stored, so intentionally broadcasting name? Ended up putting in sessionStorage, so at least preserved across reloads.

  • Customized keyboard shortcuts (keyboard shortcuts for switching tools and widths (and colors?) #57)

  • User's name (global to all boards)

As pointed out below, many of these things should be stored in user account if logged in; this issue is for not-logged-in users. The following should not be stored with user accounts though:

  • Whether touch support should be on. This is a per-machine thing, so shouldn't be stored with the user.

Saving the above settings is especially useful in a Comingle context, where we're constantly closing and reopening Cocreate rooms (including the same ones).

@edemaine edemaine added the priority High-priority because of requests or importance label May 25, 2020
This was referenced May 25, 2020
@adqm
Copy link
Contributor

adqm commented Jun 24, 2020

So I'm almost certainly an edge case, but I generally don't retain any state across browser restarts. So for me, I think that means that localstorage wouldn't actually be an effective store of anything. I think with #4 in place, it would be great to store these settings in the database somewhere, and then have the option to override them via localstorage, or something like that.

localstorage does, of course, have the advantage of not requiring #4, though...

@adqm
Copy link
Contributor

adqm commented Jun 24, 2020

I also think that if we are going to keep track of recently-visited (or bookmarked) room IDs, it might also make sense to be able to give nicknames to rooms (either as an actual global part of that room, or just on a per-user basis) to make picking the appropriate room out of that lineup easier. (oops, seeing now that this is mentioned in #6).

@edemaine
Copy link
Owner Author

Yes, this is meant to be complementary to #4 (user accounts) for those who don't want to sign in. Even if you clobber all state between sessions, localstorage would probably still be useful between tabs during the same browser session. You might close and then re-open a board, or open a new board from an existing one -- this will preserve some of your state, which I think would feel nice. Not a big deal.

I'm also interested in this because it's easier than #4, but offers at least some of the advantages. Not as much for you though. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority High-priority because of requests or importance
Projects
None yet
Development

No branches or pull requests

2 participants