This change fixes a bug that surfaces when an extent has been moved
partially "off screen." This can happen if an extent is translated so
that its left or top edges are outside of the rendered image. Prior to
this change, such extents would get cropped so that their upper-left
corners were always clamped to (0,0). This was wrong because it
fundamentally broke the extents' coorinate system. This change not only
preserves upper-left corner coordinates but also updates the width and
height calculations in extent-cropping to ensure that the new width and
height values still reflect the true "width" and "height" of an extent
even if some of that width or height is not visible in a rendered image.
This is essential for ensuring that mouse click detection works as
needed to translate screen-space coordinates of mouse clicks into local
(extent) coordinates for extent-matching purposes.
This change removes fileBrowserEntryFilterL from the public API (which
was unsafe because it could not update the appropriate internal
state when used) and replaces it with fileBrowserEntryFilterG,
a getter for the same field. Users of the lens should be using
setFileBrowserEntryFilter.
This fixes a bug where a cached image can cause a containing viewport to
honor a visibility request when the cached image is re-used. This is
almost certainly never desirable because we probably only want viewports
to scroll visible regions into view the first time they are drawn. This
change makes that so, since the Result returned by 'cached' contains the
visibility requests but its cached representation has them cleared.
This fix just completes the work that I intended to do in the previous
commit.
API change note: some functions got an additional Ord constraint on the
resource name type, but that shouldn't present any issues for
applications since Ord was already required on that type for some of the
fundamental parts of the API.
This change adds a function, Brick.Main.makeVisible, which can be used
from EventM to request that a region (specified by its resource name) be
scrolled into view on the next rendering. This requires the region to be
named in the drawing using either reportExtent or clickable (which just
calls reportExtent). If the specified region is in a viewport, this will
result in the same behavior as if 'visible' was used to wrap the
specified region.
Prior to this change, the size of a viewport's contents would be off by
one row or column if a scroll bar was enabled because we weren't
accounting for the extra row or column taken up by the bar. This change
makes it so that viewports that scroll only in one direction apply a
width or height constraint to their contents to account for the reduced
rendering area when a scroll bar is enabled.
