MuMenu

Interaction

Components

Naming convention for components

DeepMenu follows a MVVM pattern (Model, View, View Model)

• MuNode* - proxy for Model, such as MuNodeFlo
• Mu*View - SwiftUI View for [root,tree,branch,panel,node,leaf]
• Mu*Vm - View Model for [root,tree,branch,panel,node,leaf]

MuRoot* - starting point for one of more MuTree(s)

• MuRootVm - touch, corner, pilot, trees, branchSpot, nodeSpot
• MuRootView - manage UIViews for each corner
• MuRootStatus - publish changed state in [root,tree,edit,space]

MuTree* - horizonatal or vertical hierarcy of MuBranches

• MuTreeVm - select MuNode, add or remove sub-branches
• MuTreeView - SwiftUI view collection of MuBranch's

MuBranch* - one level in a hierachy containing MuNodes

• MuBranchVm - view model of a branch
• MuBranchView - SwiftUI view collection of MuNodeViews
• MuBranchPanelView - background panel for MuBranchView

MuNode* - A persistent model of items (shared by many Mu*Vms)

• MuNode - a generic node, may be shared my many NodeVm's (and views)
• MuNodeFlo - a node proxy for Flo items
• MuNodeVm - a view model for a View, may share a Node from another Vm
• MuNodeView - a SwiftUI view, has a companion MuNodeVm
• MuNodeIconView - a subview of MuNodeView for icons
• MuNodeTextView - a subview of MuNodeView for text

MuLeaf* - subclass of MuNode with a user touch control

• MuLeafTap - tap to activate, like a drum pad
• MuLeafTog - toggle a switch 0 or 1
• MuLeafSeg - segmented control
• MuLeafVal - single dimension value
• MuLeafVxy - 2 dimension xy control

MuPanel* - stroke+fill branches and bounds for node views

• MuPanelVm - type, axis, size, and margins for View
• MuPanelView - SwiftUI background
• MuPanelAxisView - vertical or horizontal PanelView

MuTouch* - capture touches which are captured by all branches

• MuTouch - manage touch's [begin,moved,ended] state plus taps
• MuTouchVm - state for root and drag nodes
• MuTouchView - view for root and drag nodes

Prefixes and Suffixes

• component instances
  • *Vm - instance of view model, such as branchVm
  • *Vms - array of [*Vm], such as branchVms
• point, size, radius, spacing
  • x* - x in a CGPoint(x:y:)
  • y* - y in a CGPoint(x:y:)
  • w* - width in CGSize(width:height)
  • h* - height in CGSize(width:height)
  • r* - radius / distance from center of a node
  • s* - spacing between nodes
• hierarchy
  • spot* - spotlight on current Node or Branch
  • parent* - parent in model hierarchy
  • children* - [child] array in model hierarchy
  • child - current child in for loop
  • super - a parent in a view hierarchy
  • sub - a child in view hierarcy

Relationships between classes and structs

• treeVm ▹▹ branchVm ▹▹ nodeVm ▹ leafVm ◃◃ node
  • treeVm to branchVm {1,} // 1:M array [branchVm]s expanded
  • branchVm to nodeVm {1,} // 1:M a branchVm has 1 or more nodeVms
  • nodeVm to leafVm {0,1} // 1:1 optional leaf
  • leafVm to node {1,1} // 1:1 one branchVm for each nodeVm
  • node to leafVm {0,} // 1:M may be shared by many or cached

logging symbols

• 0.00 🟢 start touch at time 0.00
• 0.44 🔴 end touch at delta time 0.44
• 0.33 🟣¹ single tap (² double, ³ triple, etc)
• touch∙(393, 675) coordinate of touch event
• 🧺 found cached instance
• √ 𐂷 ✎ ⬚ - status: .root .tree .edit .space
• V⃝ 1⇨0=0 vertical branch from single level to hidden
• H⃝ 0⇨1=1 horzontal branch from hidden to single level

SwiftUI restrictions

• SwiftUI Views do not modify its own state
  • So, no @State, @Binding, or @StateObject are used
  • Instead, change state in view model (Vm)
• View Model(Vm) is a class, not struct
  • fine tuned @Published to update View
  • synchronize state between devices, including: iPhone, iPad, TV, watch, Shareplay
• pros
  • @State has been somewhat buggy in the past
  • @State, @Binding, @StateObject adds semantic complexity
  • Simplify migration from UIKit with MVVM pattern
  • confusion on how to extract value from gestures
• cons
  • requires a manually enforced coding policy

SwiftLint violations - emphasis on columnwise alignment

• Column-wise comments on right side
• Finite State Machine columns for case statements
• pros
  • Human Readable; catch mistakes
  • allow column-wise cursor to edit multiple rows at a time
• cons
  • when refactoring, may need manual fixup
  • will not pass standard SwiftLint
  • requires a manually enforced coding policy
  • cannot build documentation with right column /// comments
  • maybe discarded in favor of dev team consensus

Exceptions to columnwise alignment

• lvalue = rvalue, where equals(=) sign is always single space from lvalue

     name = value
     longerName = value
  

  so, avoid

     name       = value
     longerNmae = value
  

  to allow later searches

     name =
     longerName =
  

see Baeker & Marcus using typography for source code