The problem this is avoiding makes absolutely no sense. Either I'm dumb, or
something is more deeply wrong with scroll group bounding boxes, or both, but I
don't care anymore. This works. Viva release mode.
Achieve this by adding a new hscroll group just for cursors.
That requires a slightly smarter window_to_canvas() to deal with overlapping
sensitive scroll groups. New rule is that scroll groups can overlap, but the
most sensitive one found from the top down will be chosen to translate
coordinates. This basically means don't overlap scroll groups with different
sensitivities.
In the presence of scroll groups, having a canvas-wide window_to_canvas()
and/or canvas_to_window() fundamentally makes no sense. At some point in the
glorious future we should kill those and use only item-relative coordinate
translation.
This reverts commit 03f0229bcf.
Mitigate the fallout from said overly aggressive revert: preserve the alpha
values to not break the color configuration for when the lines are fixed.
This reverts commit 780c1762 and e70c9a3
Both combined introduced various bugs:
* rubberband-selection has a scroll-offset
* region drag/drop has wrong y-offset
* ranges (loop etc) are above the playhead
* possible scroll performance hit (long unclipped
lines in h_scroll_group)
on the downside: time-grid is now no longer visible behind
the rulers. Doing that will require a different approach…
For example, if you're in a note and something about the mode changes, it's the
underlying region context that needs to change. So, seems we need a stack of
entry contexts to deal with this sort of thing.
Switching in/out of smart mode still doesn't update immediately because we
don't have the y-coordinate needed to update it.
This is needed to be able to lock the application fully on OS X, where the global menu bar would still allow interaction
even when a modal dialog is displayed.
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
