| Age | Commit message (Collapse) | Author |
|---|
|
|
|
this simplifies lua-bindings and also let's the compiler worry about
constant primitive types.
|
|
ctor.
|
|
|
|
Needs extension to Surfaces, replacing GuiSelectionChanged signal concept
|
|
|
|
fix up part of reordering behaviour
Dragging tracks/busses in the editor *below* VCAs still does not work
|
|
|
|
|
|
the edito
Use a FloatingTextEntry instead. All clever functionality from previous
implementation has been retained.
|
|
|
|
When right-clicking in the text entry, popup menu grabs focus. Consequently, the "focus out" handler is called, destroys the text entry and replaces it by the label name of the track.
When menu pops up, it tries to access to a widget no longer available.
|
|
chars" dialog.
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.
|
|
|
|
|
|
|
|
Triggered by resize drag an automation track very quickly upwards to shrink it
to the minimum. Caused by unsigned integer underflow.
|
|
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.
|
|
|
|
* no horiz space between Piano-Roll & Track
* 1:1 mapping of note's vertical space (no border)
|
|
* remove some old/unused styles
* fix plugin-ui button (hover color when active)
* consistent style for route buttons
(and related ArdourButton updates)
|
|
This reverts commit 86eb72955c76575b75a2b9e535162ca7e0612bfd.
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vertical alignment no longer depends on number of meters shown.
Looking for comments.
|
|
|
|
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.
|
|
|
|
|
|
the event handler); other canvas debugging aids;switch items_at_point() to use canvas coordinates
|
|
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".
|
|
Editor::flush_canvas() which should no longer be necessary with a sane canvas design
|
|
|
|
correctly
|
|
was. likely to be some corner case issues still and the issue of how rec-arm interacts with this
git-svn-id: svn://localhost/ardour2/branches/3.0@13934 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13898 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
editing. better, but i can still (somehow) trigger occasional misbehaviour
git-svn-id: svn://localhost/ardour2/branches/3.0@13840 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
TimeAxisView::name_label and TimeAxisView::name_entry. Not done yet, since the entry sometimes loses focus and cannot be hidden.
git-svn-id: svn://localhost/ardour2/branches/3.0@13836 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
