| Age | Commit message (Collapse) | Author |
|---|
|
Revert "Add checks for supported variant types"
This reverts commit 00ed7c81d329ebd0ce8c79081e61d02df9f669dc.
|
|
Add checks for supported variant types in 'build_control_ui'.
|
|
Signed-off-by: Robin Gareus <robin@gareus.org>
|
|
|
|
Don't try to be smart when chosing which parameters need their
automation updated but rather trust the list that was populated at
creation time when all relevant information had been gathered.
|
|
|
|
At the point of creation, the automate_button size request is wrong
since it has not the correct style yet. Instead of trying ugly hacks to
fix that, connect to the knob's size_request signal and get the button's
requisition only when needed. If the system font changes to one that has
different extents (even if the point size is the same), the UI will thus
correctly update.
|
|
A value of -1 means "let the widget use its natural size in that
direction".
|
|
|
|
|
|
|
|
With the same color code as the fader automation button on mixer strips.
This is especially usefull when use_knob is true (e.g. for a-EQ) because
the automation only shows one letter and a "Write" state can thus be
easy to miss.
|
|
By passing the current text of the automation button we can make the
dropdown menu align with the current mode. This will only work for
full-size automation buttons, not when use-knob is true, but in that
case it feels wrong to popup on top of the button anyway.
Also make the menu show on mouse down like a real dropdown.
|
|
Because all uses of the function positioning menus anchored to a widget
were as callback argument to Gtk::Menu::popup() where the caller needed
to correctly bind arguments, this led to repeated and a bit obscure code.
Wrap the logic into an helper function that takes care of all that, and
update the callers.
|
|
|
|
|
|
The existing code relies on AutomationControls for getting parameter
changes and update the UI accordingly. One case where this doesn't yet
work is preset loading, where ARDOUR::Plugin is responsible for actually
loading the preset but doesn't notify the changes to AutomationControls.
Since the input_controls vector now contains all ControlUI's that rely on
AutomationControls to get updates, just listen to Plugin::PresetLoaded()
and trigger an update of all elements in input_controls.
This is temporary until a better solution is devised to make
AutomationControls aware of preset loading.
|
|
Also merge the ControlUI local layout of dropdows with the local layout
of other control types (except FileButton).
|
|
The super rapid timer was disconnected by GenericPluginUI::stop_updating
but never connected again, so the generic UI worked often without
getting periodic update triggers anyway.
Try to disable the mechanism altogether, and see if there are updating
glitches.
|
|
It makes no sense to check for the validity of mcontrol only for
controller creation, since the remainder of the code assumes that the
controller will have been created correctly.
Replace that by an assert.
|
|
Now that there isn't an early return anymore for Dropdowns, the common
path takes care of connecting the display update code to the correct
signal.
|
|
|
|
That list is used to set the automation state of all automatable
controls when the global automation state is changed with the buttons at
the top of the generic UI window. The controls were added to the list
regardless of the automatable status, and some controls were even added
multiple times: once in build_control_ui() and once in build().
Since changing the state of non-automatable controls is wrong, only add
the control UI in build_control_ui() which already has the knowledge of
automatable or not.
|
|
Assert that all FileChooserButton created are for properties, because
the remaining code assumes that it should setup things for a property.
|
|
Since it is the only case that's completely different from others in
that it only handles properties, and uses a different signal path for
updates, don't put it in the middle, but as the first case to check for.
Code move only, no behavior change (since it should be exclusive to all
other cases anyway).
|
|
The code connected the callback to the PropertyChanged signal from the
plugin once per filepath control created. Should the plugin have several
files to open, this would be at best wasteful and at worst racy.
Connect the callback a single time, since the same callback handles all
property updates that we're interested in. Also rename the methods,
members and typedefs so that it's clear what the code is trying to do.
|
|
|
|
|
|
|
|
remove label, use tooltip (saves space, more compact layout)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also removes Route::group_gain_control() and associated machinery.
Not yet tested with Mackie or other surfaces. More work to done to
start using the group capabilities, and also potentially to add
or derive more controls as RouteAutomationControls
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
This removes the direct dependence on ARDOUR_UI/Gtk_UI for setting
tooltips. Removes inclusion of ardour_ui.h from 16 files.
|
|
This removes the direct dependence on ardour_ui.h from 39 files
|
|
|
|
|
|
|
|
Several reasons:
* This previously looked horribly inconsistent.
* The Gtk selector was broken for plugins with many presets,
making it impossible to select presets. For whatever reason,
the use of a menu fixes this bug.
* Towards a hierarchical menu for banked presets.
|
|
mcontrol->Changed is [also] subscribed to further below (input & output).
|
|
PBD::Timers
|
|
Thank <deity> for emacs ... space-uncamelcase-word-at-point FTW
|
|
UIConfiguration::color(name).
IMPORTANT: names have not been downcased and spaced yet, so many colors are not found
|
