Feedback Thread - FGU v4.7.0 and 2025-04 Ruleset Updates

[Mephisto]

Can you explain what the new „dynamic“ tag will do for columns? I think I have an idea but I’m not 100% positive what the change is to before the change.

[Moon Wizard]

The actual "column width" for child windows will vary between the defined column width and (2 * column width) - 1; instead of being fixed to exactly column width. This has the effect of removing empty space on the right edge of lists using this tag. (i.e. the Character Selection window in the beta Test channel now uses this.)

Regards,
JPG

[Ecks]

The right click menu is a nice improvement. Some feedback:

• Overall, the menu ordering seems a bit inconsistent. For example, sometimes Close Window / Minimize are at the top, other times it's the last item in the list. For example:
  Open Story records window. If you right click the blank area, Minimize and Close window are at the bottom of the list. However, if you click on a story record line item in the list, the menu is basically reversed, with the first option being Close Window.
  
  • There might be an argument to remove the Close Window and Minimize options when right clicking on a record in a list. If you wanted to close the window, you could still right click in a blank area or on the window header / frame area to get the existing Close / Minimize options.
• When right clicking on the story window, there's an option to "Create Item" but not "Create Advanced Item". The terminology also differs from the add buttons in the window, which say "Add" instead of "Create".
  
• When right clicking on an open image window, the first option is Close Window, seems like it should be the last item. Personally, I'd want Pointers to be the first option, as it's the one I use the most, though that's subjective.

Other random findings:
A number of image controls respond to left, middle, and right click instead of just left:

• Lighting tab color picker (e.g. right click and color picker opens unexpectedly)
• The color picker window (e.g. color area, sliders)
• The image layer visibility, sharing, lock/unlock, etc
• Mask Hide/Reveal buttons
• Line of Sight types (Select, Line, Square, Circle)
• And more

[Moon Wizard]

Thanks for the feedback.

* For this first pass of context menu changes, we just wanted to get the menu updated. Currently, the menu includes built-in menu options in the order registered, followed by custom menu options in the order defined in the scripts. I'm sure we'll look at refining this as we move forward.

* For the image data control tools, I'll pass along your feedback to Carl to review.

Regards,
JPG

[masteryogurt]

General Observations
Images (Player Version) (CoreRPG / 5e)
Player client's context menu has a "Synch [sic] Client View" option [Images > View > Synch Client View].

• As far as I can tell this doesn't do anything when players click it (and probably shouldn't).
• This option (and the misspelling of "Sync") is in 4.6, but it's a lot less noticeable when in radial. Which shows how much better this context menu is at unearthing options!

Character Sheets / Story / Images / Items (Possibly More) (CoreRPG / 5e)
I don't have an "Add New Item" option.

• Ecks reports seeing it, I don't have it at all. Running Mac client.
• I didn't test every location where I can right-click to add new.

Character Sheet (Tested in 5e)
Different context menu orders in Locked and Unlocked states.

• Locked menu order is
  
  1. Rest
  2. Minimize
  3. Close
• Unlocked order is
  
  1. Close
  2. Minimize
  3. Clipboard
  4. Rest

---

General Context Menu Design Feedback (UI/UX)
BLUF: I love this and my players will be very happy, too. It is closer to meeting players where they are.

But I wanted to expand on Ecks' comment:

There might be an argument to remove the Close Window and Minimize options when right clicking on a record in a list.

The new Context Menu is inheriting Radial Menu's design. But they are different types of menus, with different user expectations.

Context menus are more "specific" to a selected item. The click should act on either the window, or a distinct item (e.g. record, token, text selection, block). If there are no item-specific actions, then it's better if no menu appears on right click.

If the context menu must include window- and item- level actions, the user needs to understand which is which. One design solution is to locate window-specific actions at the end, separated by a design element like a horizontal rule.

Radial Menu had a "mixed" metaphor approach. Window-level actions like "close window" were always in the same place. Radial Menu was also a weird UI; users didn't have existing design expectations like in a Context Menu.

Example
If I right-click "Roll Ability Check", I expect context menu to pull up actions for this element and only this element.

If a context menu doesn't appear, that tells me there's no special actions. It's confusing to right click "Roll Ability Check" and see "Rest." Is the rest related to the ability?

I'd actually expect options like these:

1. "Roll Ability Check"
2. "Roll Check with Advantage"
3. "Roll Check with Disadvantage"

---

Anyway, this menu is way better at meeting players where they are. I'm excited to see it get polished!

[Moon Wizard]

* Thanks for report on the Client View Sync/Synch menu. That should only appear on GM side. Will fix in future Test build.

* For lists that already have add/edit/delete buttons in UI, I already removed the context menu duplication. (especially with current menu behavior, see below)

* I'm not seeing the change in the radial menu behavior on PC sheets. I always see Rest, Minimize, Close in that order. Maybe steps to recreate if you have them?

For a general note, the goal was to move to context menus with as little ruleset coding changes as possible; which means that the menu still follows all the previous behaviors. (i.e. menus are a composite of all control/window menus in each case, with built-in menus remaining as before. (i.e. no menu behaviors have changed; all menu options are still available; no ruleset coding was broken; etc.)

In order to do anything as detailed as your Ability Check roll example; that would require ruleset developers (not just SW, but all community developers) to greatly increase the number of menus registered and amount of coding for every control affected.

Regards,
JPG

[Moon Wizard]

I found an issue in the context menu code where the sorting could be inconsistent; just pushed an update to make those more consistent. Ruleset-generated menu items should now always come before built-in menu items; and we're talking internally about menu order of built-in items. Any changes to ruleset-generated menu items will be up to each ruleset developer.

Regards,
JPG

[Mike Serfass]

I noticed a new behavior with locking / unlocking character sheets.
The delete icon on all list items displays when the charsheet is unlocked.
Is this the new, intended behavior?

[superteddy57]

I noticed a new behavior with locking / unlocking character sheets.
The delete icon on all list items displays when the charsheet is unlocked.
Is this the new, intended behavior?

Yes, it is intended and expected now. The idea is that when unlocked you are in an "edit" mode.

[Mike Serfass]

I understand the edit mode concept. But displaying all the delete buttons right next to dice fields, which are double-clicked regularly?
When a player goes into edit mode, how frequently are they going to delete records vs having an extra layer of preventing unintentional deletes?
The players in last night's game commented on the delete buttons appearing like this, and considered it a bug and opportunity for misdeletes.