Layers

[johnwdubois]

Goals

• The goal of a "Layer" system is to allow the user to work with one layer of analysis at a time, and to store this analysis, for any relevant linguistic phenomenon (referent tracking, resonance/priming, trees, chunks, etc.); while retaining the option to add additional, independent layers of analysis using the same tools and concepts, but with completely independent analyses.
• New layers can be created at any time, and there is no limit to the number of layers that can be created and saved.
• The user selects one layer at a time to be the Active layer. The Active layer controls what is shown on the screen, for the domain in question.
• For example, if the user has previously created 2 Tracking layers, 3 Chunk layers, and 3 Resonance layers, the user can choose to display Tracking layer 2, Chunk layer 1, and Resonance layer 3, or any other combination.
• Any edits affect only the currently Active (displayed) layer, and are saved only in that layer.
• Elements in the currently Active layer may interact with each other in the usual Rezonator fashion (e.g. parallel resonance chains may be vertically aligned; two cliques may be merged; and so on), but there are no interactions across Layers of the same type.
• Different layers of the same type (e.g. two distinct Tree layers) may be structured independently of each other, allowing for maximum freedom of analysis and representation. There is no requirement that the different layers will have the same elements, structures, or analyses.
• The "exception" is that the linguistic data will always be structured according to sequences of words (tokens) and units (clauses or intonation units). Each word instance has a unique identity, symbolized by its TokenId, that always remains constant across all layers. Similarly, each unit has a unique identity, symbolized by its UnitId. Indeed, this constancy of words (tokens) and their units is what allows users to integrate information across the different layers, facilitating layer-based analysis with external tools like rezonateR.
• (The Layer system is a generalized version of Rezonator’s existing "Stacking" system, as extended to all chains such as trails and resonances, and to chunks, trees, and so on.)

What to do

1. Each (relevant) Tab in Rezonator should display a colorful button on the header bar, labeled "Layer".
2. Next to the button, a field displays the name of the currently Active layer.
3. The Active layer is the only layer that can be:
   • shown on the screen
   • edited
   • updated/saved
4. Clicking the Layer button show a drop-down list of existing Layers to choose the Active layer from, plus the option to create a new Layer (which will automatically become the Active layer).
5. Every Tab begins with its Active layer being the Default layer. The Default layer is automatically created whenever Rezonator is used, even if the user takes no special action. (It is equivalent to the data that already exists in the current Rezonator, for a given tab.)
6. Users can select exactly one layer of each type to be Active at any time.
7. When the user selects a layer that is different from the current layer
   • any changes to the previously Active layer are saved in a "save file" (actually, in a node map whose root represents a certain layer of a certain Tab)
   • the new Active layer is “loaded”.
8. “Loading” a new Active layer involves...
   • each token and unit "forgets" what entries and chains it was part of in the previously Active layer
   • each token and unit is "told" what entries and chains it is now part of, based on the newly activated Active layer
9. Relevant tabs that should have layers:
   • [x] Trail (This may be the easiest place to start)
   • [x] Stack (done, basically [= "Stacking"]
   • [x] Tree
   • [x] Resonance
   • [x] Clique (This Tab is tied to Resonance, and is not independent of it.)
   • [ ] Chunk

See also

462

1283

1397

985

[kayaulai]

I'm not sure it's a good idea to have unit layers - If only one layer can be visible at a time, that means part of the lines will always been invisible, which isn't quite intended behaviour!

[johnwdubois]

Good point about the unit layer -- I have removed it from the list.

[kayaulai]

One thing that needs to be decided from the start is how to implement chunk layers properly, because we don't want a situation where

1. A user creates a chunk in Chunk Layer 1 which is also a track belonging to Trail Layer 2
2. The user switches to Chunk Layer 2
3. Now tracks in Trail Layer 2 are gone.

There are several options:

1. Scrap the idea of chunk layers, and instead do chunk colouring: https://github.com/johnwdubois/rezonator/issues/1355
2. Each trail layer has to be associated with a chunk layer. This can be a many-to-one relationship, i.e. one trail layer can correspond to multiple chunk layers, but not the other way around.
3. Each trail layer has to be assoiated with one chunk layer and the relationship has to bijective: One trail layer corresponds to exactly one chunk layer. I'm not a fan of this one as it would create the need to create redundant chunks in many cases. However, it's probably easier to implement than option 2.

(Everything said here applies to rez as well.)

[terrydubois]

Current bugs with resonance layers:

• Crash with mergeCliques
• Crash with refreshCliques
• some entries are hesitant to align when switching layers, especially when there are 2+ chains per clique

[terrydubois]

When deleting a token, the token must be removed from all chains that it is in across all layers. If the user attempts to delete a token that is in 1+ chains of an inactive layer, we should show a dialog box (similar to the chunk dialog box for this issue) asking user if they want to remove this token from all chains that it is in.

[terrydubois]

Default layers should not use the ID "Default". Instead, when starting a new REZ file, spawn a default layer map with a random ID, similar to any other layer.