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.
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.
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.
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.
The signal exists to notify listeners that something outside of the host's control (e.g. a plugin's own GUI for AU or VST)
has modified a plugin parameter. Previous code had strange feedback loops and ambiguous semantics.
Significant modification of LV2 GUI updating was required.
Still to be tested for feedback loop issues: AudioUnits
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.
When the GUI is opened the first time all is fine, focus is on the
embedded widget. However once a user presses one of the preset buttons
(Add, Save,...) there is no possibility to return focus to the
embedded widget. Ardour always 'sees' it as focus=GtkButton and passes
the event to the editor.
A Gtk::Entry might be better here, making Gtk::Label wrap based on size is tedious...
git-svn-id: svn://localhost/ardour2/branches/3.0@12043 d708f5d6-7413-0410-9779-e7cbd77b26cf
parameters marked up as scalePoint with fewer labels
than there are possible values for the parameter
(should fix#2612).
git-svn-id: svn://localhost/ardour2/branches/3.0@11744 d708f5d6-7413-0410-9779-e7cbd77b26cf
widgets the PlugUIBase makes available for subclasses.
Give up on trying to report when a VST plugin's settings
have been modified from a preset, since I think it is
impossible to do cleanly (you set the preset, then at some
point after that the plugin tells you that values have
changed using the same mechanism that it uses to report
normal user-initiated changes).
git-svn-id: svn://localhost/ardour2/branches/3.0@10798 d708f5d6-7413-0410-9779-e7cbd77b26cf
Fixes#4364.
I havn't fully tested every single dialog and window (heck, I don't even know
how to get at half of them), and there may be some packing niggles, but this is
the bulk of the work. The Gnome 3 kiddies can close their dialogs now, anyway
:)
git-svn-id: svn://localhost/ardour2/branches/3.0@10699 d708f5d6-7413-0410-9779-e7cbd77b26cf
in generated plugin UIs (#4221). Based on work by
jeremybub.
git-svn-id: svn://localhost/ardour2/branches/3.0@10064 d708f5d6-7413-0410-9779-e7cbd77b26cf