Karya, built on 2023-08-29T07:47:28 (patch 7a412d5d6ba4968ca4155ef276a062ccdeb9109a)
Safe HaskellSafe-Inferred

Ui.Sync

Contents

Description

Take Updates, which are generated by Diff, and send them to the UI.

The C++ level and BlockC have no notion of "blocks" which may be shared between block views. The haskell State does have this notion, so it's this module's job to distribute an operation on a block to all of the C++ block views that are displaying that block.

So if this module has a bug, two views of one block could get out of sync and display different data. Hopefully that won't happen.

Implementation of merged tracks:

They need to be implemented in two places: 1. when a block is updated with changed merged tracks, and 2. when a track is updated they should be preserved. It's tricky because unlike normal track events, they are block level, not track level, so the same track in different blocks may be merged with different events. I don't actually see a lot of use-case for the same track in different blocks, but as long as I have it, it makes sense that it can have different merges in different blocks, since it's really a display-level effect.

This is a hassle because case 1 has to go hunt down the event info and case 2 has to go hunt down the per-block info, but such is life.

Synopsis

Documentation

sync :: Fltk.Channel -> Track.TrackSignals -> Track.SetStyleHigh -> Ui.State -> [Update.DisplayUpdate] -> IO (Maybe Ui.Error) Source #

Sync with the ui by applying the given updates to it.

TrackSignals are passed separately instead of going through diff because they're special: they exist in Cmd.State and not in Ui.State. It's rather unpleasant, but as long as it's only TrackSignals then I can deal with it.

set_play_position :: Fltk.Channel -> [(Id.ViewId, [(TrackNum, ScoreTime)])] -> IO () Source #

The play position selection bypasses all the usual State -> Diff -> Sync stuff for a direct write to the UI.

This is because it happens asynchronously and would be noisy and inefficient to work into the responder loop, and isn't part of the usual state that should be saved anyway.

keycaps

debug