On Intel systems ArdourCanvas::COORD_MAX (1.7e+307) was rounded
to (gint) -2147483648. gtk+ treats negative window size-requests
as 1px.
However on ARM, COORD_MAX was truncated to +2147483648, gtk+ limits
this to 65535. Most WM/Xwin systems cannot handle windows this large.
It also exceeds the max size of cairo [image] surfaces.
This issue was introduced in a1c67b4ad7
when "natural_size" was removed. Before that change infinitely large
canvas had a natural_size of 2x2 px.
The AudioClipEditor features a scroll bar that is a part of the canvas. Because scroll
groups are at the top level of a canvas, the scroll bar is necessary within a scroll
group, which causes it to get confused about the difference between its own
position within the canvas and that of the scroll group. This commit introduces
a per-Item flag, _scroll_translation, which is true by default. If false, the
item will not have coordinates translated to reflect scroll group position.
We need to be able to construct Metrics after the ruler is constructed
in order to deal with Triggers which are potentially short-lived. We
stored the reference as a pointer anyway, so it's not as much of a change
as it appears.
If there's a grabbed item (GtkCanvas only at present) then unless it belongs to the scroll
group used for scroll offset translation, the event coordinates should not be translated,
even if the mouse pointer moves into the scroll group.
This was changed in fc9840f2a9 to hard code a "false" argument describing
whether or not the child bbox had changed. This causes the parent to not
recompute its own bounding box when a child is shown/hidden, which is
incorrect. We now force it to true, which may be overkill for some purposes,
but at worst will just force an unnecessary bbox re-computation and nothing
more.
Firstly, ::compute_bounding_box() cannot allocate space, so do not try to do that here.
Secondly, if there is no allocation yet, use the CairoWidget's own size_request()
