When you select up to the end of the line, we now highlight the
remainder of the line. This means when a block of multiple lines
are selected, the highlight appears as a single contiguous
rectangle, rather than little bits and pieces.
Use the proper font metrics to calculate line height and spacing.
For Dialog size 12 (our default font), this seems to be identical
behaviour. Other fonts define more sensible leadings, so are
spaced out properly.
This also fixes highlighting having gaps for large font sizes.
Change to using Rectangle2D.Float to avoid having to cast all
of the co-ords and dimensions to ints.
Remove a magic 1.5 in the calculations in favour of using the right
properties of the text.
Stop adding descents all over the place. This stops the highlight
rectangles being slightly offset and allowing descenders to peek
out.
Also adjust the initial Y offset to include padding, and increment
it in the right place.
We now always render bottom-to-top, regardless of whether lines
wrap. Previously for wrapped lines we jumped upwards, rendered
the wrapping lines top-to-bottom, then jumped upwards once more
and carried on bottom-to-top. That made for some really confusing
code.
I was wrong -- lineLayouts didn't need to be sorted. Making it
a TreeMap was quite expensive, as it had to do a bajillion
comparisons each time a line was added (which happens every
render cycle).
This handles the direct rendering of a line, including highlighting
and wrapping.
Also change how the TextPaneCanvas stores its various properties,
so it's not doing lookups in multiple maps at once.
Issue #10
Replace TextPaneBoundedRangeModel with the default.
Seems functionally identical aside from a couple of bugs in the
TextPane one :-)
Change-Id: I2a28e7e7761224bab435b323a83c6586bda71067
Reviewed-on: http://gerrit.dmdirc.com/4084
Reviewed-by: Greg Holmes <greg@dmdirc.com>
Automatic-Compile: DMDirc Build Manager
Greg Holmes
