Mixbus in particular uses both types of tooltip so we might as well make them look the same.
N.B. The appearance is fine now on Windows but needs to be tested on the other platforms (i.e. some tweaking might be necessary).
All canvas objects share just one tooltip object which is based around Gtk::Label. The Label expands if the current tooltip text is wider than the previous text. However, it doesn't shrink again if the next tooltip has shorter text. Eventually, this results in some very strange looking tooltips (especially in Mixbus where they're used quite extensively).
Deleting the object after use will force a new object to get generated next time (at the correct size). There's still only ever one object per canvas but it's no longer persistent.
Technically it doesn't make much difference but from what I can tell, the only files which #include 'gtk2_ardour/gui_thread.h' are the source files from gtk2_ardour itself. The support libraries always #include 'gtkmm2ext/gui_thread.h' directly (which seems sensible). So for consistency's sake, let's keep it the same for libcanvas.
Invalidate all source entries from the image cache when we get our
region's DropReferences signal, while ignoring any subsequent regions with
no source.
Fixes bug #6179. Top vs. bottom seems pretty arbitrary to me, and this solves
the obscuring issue (which is quite common since there are often PC events at
the start of MIDI files), so bottom it is.
In summary:
* no antialiasing of waveviews
* no diagonal lines
* simplify clip detection
* don't use LINE_CAP_ROUND for outline
* use the wave colour when drawing outline only
Gtk coalesces multiple exposes into a single combined rect.
If _single_exposure is disabled, we break apart the individual expose rects for the canvas rendering.
The region is the un-coalesced set of rectangles that were requested for redraw. The area
is the coalesced single rectangle. In the worst cases, the coalesced rectangle could span
the entire window even though just two pixels in opposite corners were to be redrawn.
There is a problem with the verbose cursor as it is dragged across MIDI tracks. TO BE
FIXED.
The problem this is avoiding makes absolutely no sense. Either I'm dumb, or
something is more deeply wrong with scroll group bounding boxes, or both, but I
don't care anymore. This works. Viva release mode.
Achieve this by adding a new hscroll group just for cursors.
That requires a slightly smarter window_to_canvas() to deal with overlapping
sensitive scroll groups. New rule is that scroll groups can overlap, but the
most sensitive one found from the top down will be chosen to translate
coordinates. This basically means don't overlap scroll groups with different
sensitivities.
In the presence of scroll groups, having a canvas-wide window_to_canvas()
and/or canvas_to_window() fundamentally makes no sense. At some point in the
glorious future we should kill those and use only item-relative coordinate
translation.
Search scroll groups for event delivery from top to bottom rather than bottom
to top. Overlapping scroll groups still aren't properly supported by the
canvas, but currently all we care about is that the top one gets the event, so
the hscroll group (tempo lines) can be below the hvscroll group (tracks), but
the latter gets events.
Child items will be hidden when their ancestors are hidden. The old ::visible() implementation didn't reflect this. In addition,
when changes are made to hidden items (new definition of visible/not visible), don't bother to request redraws, since this will
be done when the item becomes visible again.
