Adds Label editor

[RaphaelAlvez]

Updates the label properties editor UI

Before

After

---

PR-SERVER-BOT: You can play around with it here: https://test.virtualtabletop.io/PR-2884/pr-test (or any other room on that server)

[96LawDawg]

Maybe spell out Title and Header as not everyone will know what that means. And there is potential confusion because "normal" sounds like it might be the default, but it is not. Maybe call it "regular" text?

[RaphaelAlvez]

Maybe spell out Title and Header as not everyone will know what that means. And there is potential confusion because "normal" sounds like it might be the default, but it is not. Maybe call it "regular" text?

Done

[96LawDawg]

Let me preface these comments with: I have not played around in the Properties code at all so I don't know what is a good idea and what is possible. And I don't know how far we want to take this. That being said here are some comments and food for thought:

• When you change style, the color gets reset back to black. Would be nice if that didn't happen.
• Dragging the cursor around the color changer (in Edge on Windows) adds semicolons to the css as it moves like this:
  "css": "font-size: 50px; font-weight: bold;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; color: #ff0000",
• In the style area, could we add a number picker to set the exact font size
• The placeholder text does not get the css color. Probably because it is a different css class?
• Should we add in somewhere the spellCheck and tabIndex properties?
• And are these Properties features supposed to include all of the properties in the "Other properties" area or just other significant ones?

[ArnoldSmith86]

"Other properties" currently shows properties that are defined on the widget but have no other UI. So you can at least see them.

[RaphaelAlvez]

Let me preface these comments with: I have not played around in the Properties code at all so I don't know what is a good idea and what is possible. And I don't know how far we want to take this. That being said here are some comments and food for thought:

Thanks. I also don't know how far we want to go with it so I'm glad for the feedback and suggestions.

I want to find a balance between simplicity and usefulness. I want it to cover 90% of simple games while not feeling overwhelming.

obviously this balance cannot be found without ohters feedback. Now that it represent that we have

• When you change style, the color gets reset back to black. Would be nice if that didn't happen.
• Dragging the cursor around the color changer (in Edge on Windows) adds semicolons to the css as it moves like this:
  "css": "font-size: 50px; font-weight: bold;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; color: #ff0000",

Both problems are quite related. I think I'll just use object css. It will make chaging text styles so much easier.
I actually forgot to check the JSON. As the ;; don't affect the result I didn't catch that

• In the style area, could we add a number picker to set the exact font size

I didn't even think of it. Maybe I'll make a text style bar so it can also be used in other places

something similar to this but that will be applied to the whole label

covering:

• bold
• italic
• color
• fontsize
• font

• The placeholder text does not get the css color. Probably because it is a different css class?

Yes because I was trying to keep the css in the string format. As I said I'll move to object format

• Should we add in somewhere the spellCheck and tabIndex properties?

I opted to not add them because they feel very niche. as ArnoldSmith86 said, If they are defined in a game they will be displayed in "other properties". If you feel they would be usefull I can easily include them.

• And are these Properties features supposed to include all of the properties in the "Other properties" area or just other significant ones?

I have plans improvethe other properties part. It will remain as a fallback for any property set in the JSON editor but I want to group comon properties and group systematic properties (Routine for "automation" and css for "apearance")

[96LawDawg]

something similar to this but that will be applied to the whole label

Great. And we could reuse that for many different kinds of widgets

• Should we add in somewhere the spellCheck and tabIndex properties?

I opted to not add them because they feel very niche. as ArnoldSmith86 said, If they are defined in a game they will be displayed in "other properties". If you feel they would be usefull I can easily include them.

No need to add those. They do show up if the default is changed. But maybe we should have 2 catch-all categories at the end. One for widget specific properties like spellCheck for labels, but other things for other widget types. Call it "Other Widget Specific Properties" or whatever. And one for global properties like we have now called "Other General Properties."

I have plans improvethe other properties part. It will remain as a fallback for any property set in the JSON editor but I want to group comon properties and group systematic properties (Routine for "automation" and css for "apearance")

Grouping similar properties is very important because alphabetical listing in the JSON Editor is not intuitive. For example, maybe we make a Positioning group: x, y, layer, parent, rotation. Maybe a Visibility group: display, hidePlayerCursors, linkedToSeat, owner, onlyVisibleForSeat. Maybe a Size group: width, height, scale. Maybe even the "Other properties" could get sub-categories (with expandable headers so all of this doesn't show up): Movement (dragLimit, grid, movable, movableInEdit)

Other widget types get their own groups. For example, a basic widget could have Content: faces, html, icon, image, text.

I don't want to overcomplicate this as I think the 90% solution is a good goal.

[96LawDawg]

Another thing I just tested. If I have the nested object form of css, then changing color does nothing and changing style/font-size erases the other css. I don't know many people that would use nested object css and then use the Properties sidebar, but we should probably prevent it from being destructive to what is already there including if it is just the basic object form. This may be difficult to code.