-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: Word-wrap functionality for MultilineTextBox #984
base: dev
Are you sure you want to change the base?
feature: Word-wrap functionality for MultilineTextBox #984
Conversation
- added DisplayText property to TextInputBase - added virtual ProcessDisplayText method to TextInputBase - modified TextInputBase to draw new DisplayText instead of Text - added WrapText and WrapTextSegment overloads to DrawUtil with out parameter that contains the indices of the added new line characters - modified DrawUtil.WrapTextSegment to stop adding an additional space character to the end of the text segement - added DisplayNewLineIndices property to MultilineTextBox - added GetCursorIndexFromDisplayIndex and GetDisplayIndexFromCursorIndex methods to MultilineTextBox to switch between cursorIndex and displayIndex - modified MoveLine, GetCursorIndexFromPosition, CalculateHighlightRegions and CalculateCursorRegion in MultilineTextBox to be based of the DisplayText instead of Text - implemented new virtual ProcessDisplayText override in MultilineTextBox - added ApplyWordWrap method in MultilineTextBox - modified GetSplitIndex in MultilineTextBox to return the line and character based on the DisplayText instead of the Text - modified RecalculateLayout in MultilineTextBox to include recalculation of the DisplayText - added HandleDelete override in MultilineTextBox to include a recalculation of the layout after characters were deleted
I think it would desirable to make this a setting and make it the default.
After playing around some with the build, I believe the prior. If you don't break somewhere then it just extends completely off the screen and isn't visible. Maybe that isn't likely to happen, but I imagine it could for smaller inputs or depending on how the module dev is using it. The rest of the changes seem safe. I didn't notice any issue when running through a couple of things. |
Thanks for the testing and feedback! Will probably submit changes sometime in the next couple of days. |
- added wrap-functionality in the middle of a word - added DisableWordWrap property on MultilineTextBox - added WrapCharacters property on MultilineTextBox - added WrapWord method to DrawUtil - modified WrapTextSegment and WrapText methods in DrawUtil to wrap words that are too long to fit in a single line - added overloads to WrapTextSegment and WrapText methods in DrawUtil to allow for additional wrap characters where a word may wrap.
…ments finishing touches on word-wrap for MultilineTextBoxes
Added word-wrap functionality in the middle of a word.With the added changes
Final thoughtsI thought about adding a dash As I mentioned above, the changes to the utility functions do affect other places in core and may also affect some modules. The new changes to breaking a word in the middle have larger ramifications than the removed space above. This could be avoided by introducing a new method If the changes should eventually be brought over to other places like Implementation details
|
- modified blish-hud#992 to be compatible with blish-hud#984
…changes in MultilineTextBox
…ments added minor fixes to MultilineTextBox
Adds word-wrap functionality to the
MultilineTextBox
. Related to #620.DisplayText
property that may be manipulated by inheriting classes ofTextInputBase
. The currentText
property retains its functionality while theDisplayText
makes it possible to change the text that is drawn onto theControl
.DisplayText
property inMultilineTextBox
to apply a word-wrap.notable behaviour changes
MultilineTextBox
es will have word-wrap applied to them. See "open questions" below for alternatives.DrawUtil.WrapTextSegment()
stops adding an additional space character to the end of the text segment. The previous behaviour is assumed to be a bug. This change affects Blish Core in 3 places (SpriteBatchExtensions.DrawStringOnCtrl()
,FormattedLabel.InitializeRectangles()
andLabelBase.GetTextDimensions()
). The consequences at the time of writing are unclear and need to be tested. It's also unclear if any modules rely on that method.open questions
MultilineTextBox
(as it is implemented in this PR), or is it desirable to have a propertyAutoWordWrap
or something like that on theMultilineTextBox
so the current behaviour is still possible?Implementation details
added
DisplayText
property toTextInputBase
added virtual
ProcessDisplayText()
method toTextInputBase
modified
TextInputBase
to draw newDisplayText
instead ofText
added
WrapText()
andWrapTextSegment()
overloads toDrawUtil
with out parameter that contains the indices of the added new line charactersmodified
DrawUtil.WrapTextSegment()
to stop adding an additional space character to the end of the text segementadded
DisplayNewLineIndices
property toMultilineTextBox
added
GetCursorIndexFromDisplayIndex()
andGetDisplayIndexFromCursorIndex()
methods toMultilineTextBox
to switch between cursorIndex and displayIndexmodified
MoveLine()
,GetCursorIndexFromPosition()
,CalculateHighlightRegions()
andCalculateCursorRegion()
inMultilineTextBox
to be based of theDisplayText
instead ofText
implemented new virtual
ProcessDisplayText()
override inMultilineTextBox
added
ApplyWordWrap()
method inMultilineTextBox
modified
GetSplitIndex()
inMultilineTextBox
to return the line and character based on theDisplayText
instead of theText
modified
RecalculateLayout()
inMultilineTextBox
to include recalculation of theDisplayText
added
HandleDelete
override inMultilineTextBox
to include a recalculation of the layout after characters were deletednotable Cons
TextInputBase
subclasses.Discussion Reference
All new features must be discussed prior to code review. This is to ensure that the implementation aligns with other design considerations. Please link to the Discord discussion:
https://discord.com/channels/531175899588984842/536970543736291346/1285731312056930339
Is this a breaking change?
Breaking changes require additional review prior to merging. If you answer yes, please explain what breaking changes have been made.
No