Limit-Theory-Redux / ltheory

Limit Theory Redux is a fork of the discontinued open-world space simulation game Limit Theory. We have made it our mission to continue the development of the ambitious Limit Theory project as an open source initiative.
Apache License 2.0
58 stars 7 forks source link

Text editing #284

Closed HaronK closed 1 month ago

HaronK commented 2 months ago

TODO:

* mandatory

Flatfingers commented 2 months ago

This looks fantastic, and I can't wait to get to start using it! That list of styling features where supported -- underline, strikethrough, line and letter spacing, etc. -- looks amazing.

Also, the editable property is great to have. It does make me wonder: should we define a define a style guideline that says non-editable text -- a label -- should be implemented using the Text component rather than TextView unless the text is multi-line and/or requires detailed style formatting? (Alternately, should we rename the Text component to Label?)

In the active behavior of the TextView component, I noticed several small things (the first and third of which are shown in the screenshot below):

  1. When clicking and dragging to highlight text from right to left, and dragging all the way to the start of the line, the first character in a single line is not highlighted. (Clicking and dragging from left to right does highlight the final visible character on a single line as expected... but see item 2 below.)
  2. When clicking and dragging from left to right, dragging the cursor beyond the last character in a (non-terminal) line makes the cursor "jump" to the start of the following line. I'm guessing this is because of the newline character at the end of every line.
  3. When clicking and dragging (either direction) to highlight multiple words, the spaces in between words/characters are not highlighted. However, when text containing a non-highlighted space is pasted, the space character is pasted correctly -- it just isn't being highlighted in the TextView text area.
  4. When you add a callback to editable text (non-editable text is not affected by this), the first time you click anywhere in that TextView text area, the callback is triggered -- even if you don't change anything. After this, the callback is triggered only when you actually change some text in the TextView text area.

image

If you feel these behaviors are OK for the moment, I'll be happy to approve this and we can discuss what (if anything) to do about these notes later. If you would rather make changes now before I approve, that is fine with me as well.

HaronK commented 2 months ago

I'm planning to keep this PR open until all small issues and glitches are fixed. At least non complex ones.

1-3. These are what I mentioned about glitches in my message on Discord. Will fix them.

  1. Will take a look at it.

Just post here all your findings and I'll check them. Especially on Win/Mac platforms. Also it would be nice to check performance. For me it shows now 17-18ms. But it's a simple view with 2 text views, so in more complex view it could be higher.

Regarding old text element. I'd prefer to replace it completely with TextView(multiline=false, editable=false) to unify things. So use TextView in all new code and replace Gui:text() with it in the old one gradually.

Flatfingers commented 2 months ago

Items 1-4 look good now -- thanks!

One new item: Say you have a block of text spanning multiple newline-terminated lines. Pick any line other than line 1. When you click and drag from somewhere in the middle of a line to the start of that line and then release the mouse button, the cursor "jumps" to the end of the previous line.

HaronK commented 1 month ago

Items 1-4 look good now -- thanks!

One new item: Say you have a block of text spanning multiple newline-terminated lines. Pick any line other than line 1. When you click and drag from somewhere in the middle of a line to the start of that line and then release the mouse button, the cursor "jumps" to the end of the previous line.

This should be fixed now. There is still a problem with selection highlighting - it not always properly shows start and end of the selected region. Another problem - overlapping/shadowing letters in the highlighted region. Will address these issues on weekend.

Flatfingers commented 1 month ago

OK, functionality looks good and I'm ready to approve.

One request: Now that editing in the TextView component is working, please either change all of the temporary credits text to something like "Test Credits" (so that no one is credited yet), or add two lines:

Visual Designer:
BFett

in the same style as the existing credits.

I'd rather have no credits at all just yet, because there is still a lot of work remaining to be done in many areas; the names will be changing. But if it's easier for you to leave the temporary credit text in place, please add BFett who has already done a great deal of work on the project. Thanks!

HaronK commented 1 month ago

@IllustrisJack already updated Credits.lua in his PR, so I'll merge his changes. Will add BFett if he is not in yet.

IllustrisJack commented 1 month ago

OK, functionality looks good and I'm ready to approve.

One request: Now that editing in the TextView component is working, please either change all of the temporary credits text to something like "Test Credits" (so that no one is credited yet), or add two lines:

Visual Designer:
BFett

in the same style as the existing credits.

I'd rather have no credits at all just yet, because there is still a lot of work remaining to be done in many areas; the names will be changing. But if it's easier for you to leave the temporary credit text in place, please add BFett who has already done a great deal of work on the project. Thanks!

My pr is merged now, i´ve added BFett in the credits aswell and also created a function to create the formatted credits from a lua table. If we are going to have some place where we can fetch the credits easily (like a file in the repo) we can automatically update it from that with some code