Feature 190

[BryonLewis]

Fixes #190

• Adds into the user Settings a prompt setting for prompting the user when deleting objects.
• Restructured NewTrackSettings into having TrackSettings with a new DeletionSettings. It is one value for now but I don't know if more will be added in the future.
• CreationMode has been renamed to TrackSettings to more accurately reflect being tracksettings
• The localStorage uses the same format just with an additional field.
• Updated the useModeManager handleRemoveTrack to prompt if the user settings indicate so. There is an option override which is used for track visibility deletion tool (The delete button next to track settings).

• Not a huge fan of having the multiple top-level items in the storage but I didn't want to interrupt anyone's current track creation settings.

[subdavis]

We should be vigilant about naming and avoid proliferation of symbols with names that 1) aren't very descriptive and 2) are very close to other things. There's a similar problem in common.ts in desktop.

Stuff like this really impacts readability because rather than relying on intuition, you have to rely on bulk memorization to know what things do.

Please hold me accountable to this as well.

Rather than introduce 2 more symbols to the useSettings namespace, could we just rename NewTrackSettings to TrackSettings add promptUserOnDelete to TrackSettings.

Putting DeletionSettings into its own namespace doesn't make sense, because if we end up with settings that affect other types of deletions (users, types, etc) then we can't put them in DeletionSettings because it's a child of TrackSettings.

Then, updateNewTrackSettings should move to simply updateTrackSettings.

I'd actually prefer to do away from putting settings into these arbitrary groups at all and have a AnnotatorSettings interface and a updateSettings() function and never have to add new symbols to the useSettings api, but this could be out of scope for this PR.

[BryonLewis]

I'd actually prefer to do away from putting settings into these arbitrary groups at all and have a AnnotatorSettings interface and a updateSettings() function and never have to add new symbols to the useSettings api, but this could be out of scope for this PR.

Understood and I wasn't a fan either considering my last bulletpoint. I'll swap it, I was just avoiding doing an update to users who currently had data in localStorage stored a top level newTrackSettings

[subdavis]

I was just avoiding doing an update to users who currently had data in localStorage stored a top level newTrackSettings

On the balance, maybe don't bother? Just change the name of the variable and let users's settings be overwritten with the defaults. It's just a couple toggle switches. I don't think I'd bother attempting to migrate them.

[BryonLewis]

I need to do some double checking of stuff, and I think refactoring some of the components to composition and using toRef so I can maintain reactivity and not have these long property chains.

[BryonLewis]

Okay I think I have this working like it should. a reactive AnnotationSettings object is passed around and depending on where it is used the sub-settings are converted to a ref using toRef so they maintain their reactivity and can be used in vue templates while destructuring the property.
This keeps everything using the type of AnnotationSettings and the toRef will maintain the proper type with the wrapper of a Ref<SubSettingsType so it can be properly used.

[subdavis]

LGTM, one nit.

[subdavis]

ambiguous boolean. Does override mean to force enable or force disable? Could this be renamed to forceEnable or forceDisable based on what it is supposed to do?

[BryonLewis]

are you good with forcePromptDisable? just so you know what you're force disabling.

[subdavis]

Yep sounds good.