Plugin inline displays were forbidden to shrink as this might cause a deadlock
when the shrinkage causes the scrollbar to disappear.
display shrink → scrollbar unneeded → scrollbar disappears →
more horizontal space -> display grows -> scrollbar appears →
less horizontal space -> display shrink and so forth
This was formerly avoided by not allowing display shrinkage.
The solution proposed here sets the maximum height of the display to the
current height, if a scrollbar is present during resizing and has not been
present during the last resizing. So if this scrollbar disappears (after
resizing it might no longer be needed), the display would have the possibility
to grow, but it does not grow vertically as the maximum height is limited to
the current height.
Only PluginInserts have UIs and PinMgs and unique IDs.
Other processors may not be saved explicitly, [re-]created
dynamically, change ID (eg. capturing processor) and clutter up
the list.
TODO: removing a processor should also remove its UI state.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Depend on Changed() signals alone, which are usually much less frequent
than rapid-timer events.
As side-effect we now need to make the widgets insensitive when
playing automation. Previously the user could not change the value because
the Timer periodically reset it.
Route::before_processor_for_index() uses display_to_user() which
includes the Amp.
Insert position is still be wrong with the debug mode
ProcessorBox::show_all_processors == true, but that's not a regression.
This reverts commit b3722f7063.
In some cases ardour shows context-menu on right-mouse-button
release. In this case selecting a menu-entry should happen
with the left-mouse button (or any button?!)
Using ev->button is only correct if the menu is temporary and only
visible while the button is held, button release then activates the
menu-item.
This needs further work, in some cases allowing any button (0) to work
makes sense and overall consistency needs to be improved.
Different places use different strategies for context-menus which
don't always match the button used in the event-handler.
This is a hotfix (to make TAV context menus work again with left-click)
Both views have uncorrelated geometry, apply one size to the other
makes no sense and usually results in odd window sizes, particularly
for custom plugin UIs with aspect-ratio constraints.
