This change helps users avoid undesirable behavior by accidentally
using the wrong type of renderer to draw a scroll bar. This change:
* Splits up the ScrollbarRenderer type into two new types,
VScrollbarRenderer and HScrollbarRenderer, with nearly identical
fields except that each field now has some 'V' or 'H' in it.
* Renames 'scrollbarAllocation' to 'scrollbar(Height|Width)Allocation'
depending on the renderer type.
* Updates the Core API to take values of the new renderer types as
appropriate.
* Updates the types of the default renderers.
* Updates the demo program that uses the custom renderers.
This change is motivated by a desire to be able to control how scroll
bars are rendered adjacent to viewport contents. It isn't always
desirable to render them right up against the contents; sometimes,
spacing would be nice between the bar and contents, for example. In
general, we want users to be able to control more aspects of how scroll
bars are drawn. This change is a step in that direction. This change
won't affect any users who are using the default scroll bar renderers.
This change:
* Adds a new field to ScrollbarRenderer, scrollbarAllocation :: Int,
which specifies the height (for horizontal scroll bars) or width (for
vertical ones) of the region in which the bar is rendered. This allows
scroll bar element widgets to take up more than one row in height (for
horizontal scroll bars) or more than one column in width (for vertical
ones).
* Updates the scroll bar rendering logic to clamp scroll bar handles to
one row in height (for vertical scroll bars) or one column in width
(for horizontal ones) since we need to be able to assume the size
of the handles when computing the size of the scroll bar and trough
regions.
* Updates programs/ViewportScrollbarsDemo.hs to demonstrate the use of
the new allocation feature to draw a vertical scroll bar that takes up
more than one column in various ways.
This fixes a critical problem in KeyDispatcher where it would previously
silently ignore all but one handler for a specified key if the key
configuration resulted in the same key being mapped to multiple handlers
(either by event or by statically specified key).
This change is motivated by the API wart that results from the
overloading of both "<>" and string literals that resulted in code like
this:
a :: AttrName
a = "blah" <> "things"
While this worked to create an AttrName with two segments, it is far too
easy to read this as two strings concatenated. The overloading hides
what is really going on with the segments of the attribute name. The way
to write the above example after this change is:
a :: AttrName
a = attrName "blah" <> attrName "things"
