Screen write/writeWrap methods and convenience operators. #22
Conversation
|
Let me know if you want any changes or perhaps to add something extra. As you can see, I've added the demo of the changes that can be conveniently executed with |
|
I'll need a little time to go through this. I just made a massive number of changes in tcell itself but its been a while since I looked at dcell. |
| * y = Y coordinate (row) to start writing at | ||
| * s = string to write; each Unicode scalar value maps to a single cell | ||
| */ | ||
| final void writeWrap(size_t x, size_t y, string s) |
There was a problem hiding this comment.
I don't want to commit to writeWrap.
The problem with this method is that while it may be convenient, what folks want from a semantic point of view can vary, to the point that I think it doesn't offer enough value on it's own.
Specifically people will wonder:
- Does it start continuing at the same x offset, or at offset 0? (Arguments exist for both interpretations!)
- Should it handle an embedded newline or carriage return?
- What about style when wrapping? Especially if the x offset is not zero, do we rewrite the style at offset x, or at 0?
- Can I have word wrap too? Why or why not?
- Does this properly treat wide characters? (I don't think it does).
My first instinct was that this was going to be a good thing, but then I started thinking about these questions, and realized it was a can of worms that I think we shouldn't try to solve. Instead this belongs in a higher level API.
| unit = " "; | ||
| } | ||
| this[x, y] = unit; // preserves style | ||
| ++x; |
There was a problem hiding this comment.
This does not handle wide characters, nor grapheme clusters.
| while (i < s.length && x < cast(size_t) sz.x) | ||
| { | ||
| auto start = i; | ||
| decode(s, i); // advances i to next code point start |
There was a problem hiding this comment.
I'm coming to believe (and i've done this in tcell) that its important to handle grapheme clusters. This means that a simple decode by code point is insufficient.
|
Excellent! Thanks for the review. I will try to find some time to work on this over the weekend. |
|
I've made a grapheme aware version of these in #51. I also used a different approach with a stateful "position" (cursor) in the screen/cellbuffer itself, which leads to a simpler function signature. I'm probably going to commit #51 instead of this. I do however appreciate your effort, and certainly having this in front of me encouraged me to think a bit harder about the API, to ensure that we make available to our users is as easy as possible. |
|
I'm closing this -- I think #51 resolves this more nicely. Thank you however. |
Does more/less what was explained in the #3
This PR introduces convenient helpers on
Screento make writing text and styles far simpler, plus atiny demo showcasing the new changes. All additions are implemented as
finalhelpers onScreen, soevery backend benefits automatically without changes.
Since I expect all the added methods to be in every implementation of Screen I have
added them there as final methods. If it is believed not to be the case I can move them to
the TTYScreen.
As described in the dcell issue #3 we now have opIndexAssign convenience methods to help us
set cell text and style via index assignment.
We also have multi-cell string and style writing helpers write() and writeWrap(). First one truncates
at the end of the row, second wraps across rows. Without style parameter they will preserve existing
style. There are also styled variants that apply the provided style to each written cell.
I've also added the demo demos/screen_write_strings.d that shows all the new features.