The dialog would be created twice, once because the user hit enter etc. to indicate they were done editing,
and once because focus left the name text entry, also indicate the end of editing. We now note that we're
already processing the end of a name edit, and do nothing in that case
preparation for further Summary and Number of visible
track count fixes.
* “Only Self”: don’t resize child-views (old default)
* “Total Height”: distribute height equally among
all visible child [automation] lanes
* “Height per Lane”: given height should be applied
to all sub-views.
Also push the increasingly unwieldly paste parameters into a context object.
As with othe things, currently it is only possible to do "cross-type paste" by
explicitly selecting the target track. We will need to get automation region
view selection working to do better here, but at least for now it's possible to
get the data over.
The idea here is to do the reasonable thing, and copy objects of some
type (e.g. MIDI region, gain line) to tracks with a matching type. The user
can override this with a track selection, which will be used straight-up.
Lost: ability to copy/paste lines across types, e.g. gain to pan. This is
often questionable, but sometimes useful, so we will need to implement some
sort of "greedy mode" to make it possible. Implementation simple, but not sure
what to do. Perhaps this should only be possible if one automation track is
explicitly (i.e. via track selection) involved, and the types are at least
compatible-ish?
The idea here is that pasting several times to the same location doesn't make
sense. Instead, the paste is appended past the last paste, snapped to the
grid. This make it simple to replicate a given section a number of times,
simply by copying once and pasting several times.
This behaviour only appears when successive pastes are done to the same
location (whatever the edit point is). When the paste point changes, the
"multi-paste" state is reset.
Boots 'n cats 'n boots 'n cats.
* remove some old/unused styles
* fix plugin-ui button (hover color when active)
* consistent style for route buttons
(and related ArdourButton updates)
XXX: If we keep this approach, TimeAxisView::show_at()
needs to be fixed.
TimeAxisView::_canvas_display should draw the separator
line at the top, and regions inside moved down 1px.
the track-header minimum width is defined by
the name-label (IFF the 2nd row fader is not visible,
but the fader is rather small by default and and grows)
track-header width in almost all cases is:
name-label width
+ width of three button (1 char each)
+ max size of all meters (if visible)
+ width of MIDI scroomer (if visible)
+ 2px table cellspacing (per column)
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.
Delivery of fake motion events to the editor needed the event coordinates to be
in canvas space, as they are with "real" events. Editor and other objects had
many redundant groups from timbyr's work on gnomecanvas to scroll by moving
groups. We don't need this anymore with cairo-canvas (though possibly a
stationay background group for the canvas might be useful again one day as in
the SAE logo. Its implementation would be fairly different though, since we
would have to explicitly move the group on every scroll, since nothing else
ever moves on scroll).
Also tweaks to text item placement, and switch TimeAxisViewItem from
name_pixbuf to name_text, since ArdourCanvas::Text is already "pixbuf optimized".
