If _size_menu was non-null, we just return it. Ergo, it was already null when we reached
this line, which makes calling delete on it completely pointless
This test was added because of confusion about when/where dynamically constructed menus
were constructed and deleted. This should be consistent now, and this additional check
(on top of _size_menu itself being null) should be unnecessary
This supersedes 0708cdb6b4, an explicit `name_label.show()`
is not needed. The inactive label was missing an explicit call
to show.
This also fixes MIDI track MIDNAM Selector visibility
Inactive tracks will now hide all controls and display only the track name
in parenthesis.
Color-change is not sufficient by itself to distinguish an inactive track
from an active one (consider the case of just 2 tracks...)
Parent class d'tor runs after derived class d'tor. By the time
~TimeAxisView() is called, the actual object has already been
deleted and dyanamic_cast<RouteTimeAxisView*> or
dynamic_cast<AutomationTimeAxisView*> will fail.
CatchDeletion() needs to be emitted from the actual d'tor of the object.
There are currently three non-virtual TAVs:
* RouteTimeAxisView
* AutomationTimeAxisView
* VCATimeAxisView
The first two already directly emit CatchDeletion(), there's no need to
call it again from ~TimeAxisView().
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
use Requisition Gtk::Widget::size_request () const;
and not deprecated
void Gtk::Widget::size_request (const Requisition&);
Found by PVS-Studio - https://www.viva64.com/en/b/0540/
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
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)
