[Liminal UI] implement new design for Gesturemenu Commands

[cindmichelle]

Close #3709

Summary

Replace the old CommandItem-based gesture list with a new GestureItem component and redesigns the Gesture Menu command layout.

Changes

New GestureItem component (src/components/GestureItem.tsx)

• Command row for the Gesture Menu showing a gesture diagram, label, and expandable description when selected
• Uses solid-color, no-glow GestureDiagram (no gradient, no arrowhead) suited for compact list display

New useGestureHighlight hook (src/hooks/useGestureHighlight.ts)

• Extracted from CommandItem, drives the highlight prop on GestureDiagram
• Handles special cases: suffix matching for openMobileCommandUniverse, fixed highlight of 1 for cancel

Gesture Menu layout (src/components/GestureMenu.tsx)

• Added "Gestures" header with gradient divider
• Splits commands into two groups: main commands and a visually separated Cancel/Cheatsheet block at the bottom (28px gap)

GestureDiagram enhancements (src/components/GestureDiagram.tsx)

• New props: arrowhead='none', disableGlow, useGradient, highlightColor
• Extracted rendering logic into a GesturePath component
• Solid-color mode uses a single combined <path> per stroke group to eliminate bead artifacts at joints from overlapping round caps
• arrowhead='none' uses uniform symmetric padding for the viewBox instead of asymmetric arrowhead padding
• RDLD Bezier segments extracted to a named constant

---

Results

ios

ipad

---

Notes

This PR will only focus on redesigning the command list inside the Gesture Menu. Any upcoming layout changes related to splitting the menu into few columns will be handled in a separate ticket

[cindmichelle]

this one needed in order to make the new header renders above the glow background

[BayuAri]

[Mobile] Selected inactive gesture command is blurred when there is no thought available

Step to Reproduce

1. Open em
2. Delete all thought if any
3. Swipe any direction and select any grey gesture command and hold for example: swipe →↑ and hold

Current behavior

The selected menu is blurred, on this step as example: Context View
If user draws a gesture that is greyed out on the gesture menu, the command will be blurred.
This does not happen when there is a thought available.
I think this happens when the greyed out font is highlighted due the active selection on the gesture menu

Selected.inactive.gesture.command.is.blurred.when.there.is.no.thought.available.MP4

Expected behavior

The selected inactive gesture menu should not be blurred, refer to when there is thought available.

[BayuAri]

List of issue:

• [Mobile] Selected inactive gesture command is blurred when there is no thought available

There is no other issue found from my end.

[cindmichelle]

Hi @BayuAri , good catch! ive made a fix for the issue above. I also attached how the fix looks like now. and since this is the only issue atm, im going to ask @fbmcipher to review the work as well

gesture-ru.mp4

[BayuAri]

@cindmichelle
Confirmed fixed.
Inactive (unavailable) command is displayed as grey font without glow.

[fbmcipher]

All in all this is really solid – the new useGestureHighlight abstraction is a meaningful improvement, the code is strong, and the implementation is really close to the mockup. Great work!

That said, I want to push this a little further and get it as close to 1:1 with the design as we can. That's the level of quality we're aiming for, and I think we can get there.

A couple of process suggestions:

• Keep the reference mockup open beside the running implementation while you develop. Side by side, the differences are much easier to spot.
• Try xScope. I use it constantly when I implement UIs from mockups and it's been a major help. Two tools in particular:
  • Guides for measuring spacing between elements. For example, this is how we can clearly see the GestureDiagram is slightly larger than it should be. The numeric values aren't 1:1 pixel measurements (the mockup is at 200% scale in Photoshop and the iOS simulator is sized by eye to match), but the relative differences still help quantify the disparity.
  • Loupe for color comparison.

In all the notes below, left is the reference design, right is the current implementation. The majority of issues are font weight, sizing, and spacing — these are hard to translate 1:1 even with the raw Figma values, which is exactly why a measurement tool helps.

---

1. Font mismatch

Note: We haven't added the new UI font (Radio Canada Big) into main yet, so this isn't really a fault of your implementation per se. That said, since we're pushing for 1:1, I should flag it now.

• Reference: UI font is Radio Canada Big.
• Implementation: Helvetica on iOS, Roboto on Android.
• Fix: Include Radio Canada Big in the app and use it for all Gesture Menu UI. (We'll migrate the rest of the app's UI in follow-up PRs.)

2. "Gestures" header is too thin

• Reference: Semibold.
• Implementation: Light.
• Fix: Increase the font weight.

3. Command subtitle is too thin

• Reference: Regular.
• Implementation: Thin.
• Fix: Increase the font weight.

4. Gesture diagram is too large

• Reference: Smaller diagram, leaving more breathing room next to the label.
• Implementation: Slightly oversized.
• Fix: Reduce the gesture diagram size to match.

5. Too much space between the "Gestures" header and its divider

• Reference: Header sits closer to the underline.
• Implementation: ~2–3px more space than the mockup.
• Fix: Tighten the gap between the "Gestures" header and the line beneath it.

6. Not enough space between the highlighted command and the next command

Measure the gap between the end of the highlighted command and the start of the next command.

• Reference: Larger gap below the highlighted row.
• Implementation: Slightly smaller.
• Fix: Increase that gap.

7. Too much space between non-highlighted commands

Measure the gap between consecutive non-highlighted commands.

• Reference: Tighter row spacing.
• Implementation: Slightly larger.
• Fix: Reduce the vertical gap between non-highlighted command rows.

8. Gap to the "Cancel / Command Universe" block is too large

• Reference: Smaller separator gap.
• Implementation: Larger.
• Fix: Reduce the spacing between the main command list and the Cancel / Command Universe block.

9. Empty space above "Cancel / Command Universe" when there are no other commands

• Reference: When the main command list is empty, the Cancel / Command Universe block sits flush at the top.
• Implementation: There's still empty space above it.
• Fix: When the main command list is empty, suppress the top margin / separator gap above the Cancel block.

[fbmcipher]

Documentation looks good! Just a minor style note to prefer specifying parameter comments inline wtih the type for better IntelliSense – rather than the older JSDoc style.

const useGestureHighlight = (
     /** Comment. **/
    command: Command,
    /** Comment. **/
    gestureInProgress: string | undefined,
// ...

[cindmichelle]

@fbmcipher Thanks for the feedback! Initially I kept using Helvetica and Roboto font because I noticed the Command Center implementation was still using the default font, so I assumed the difference between the design and the application fonts might have been intentional 😅

Looks like I can download the font assets from Google Fonts. But do we need to import the font with specific file extension? By default, it will be downloaded as .ttf file from Google Fonts

[fbmcipher]

@cindmichelle The way you've got it with .woff2 looks perfect!

[cindmichelle]

Hi @fbmcipher , thanks for the xScope recommendation, it’s really helps me to compare the mockup sizing against the simulator!

I also noticed that you already enabled the spacing indicators in Figma. It’s been really helpful for implementing the spacing based on that, because earlier I was having a bit of difficulty implementing the spacing since I couldn’t inspect the distances properly. I hope we can also have this indicator for all components!

---

I’ve also updated the PR again to make the font-family and spacing closer to 1:1 with the mockup. One thing worth mentioning though is the GestureDiagram behaviour, as I’m still struggling to make the sizing and display match the mockup exactly due to the SVG aspect ratio being preserved.

As a result, gesture paths with a width/height ratio 1:2 (e.g Select Between) and 2:1 (e.g New Subthought) are ended up being displayed smaller compared to other gesture diagrams with a 1:1 ratio. Do you think this behaviour is acceptable?

[cindmichelle]

@fbmcipher in my last commit, i also tried to reduce the padding around the gesture path so we could have more space to render the gesture path. but could you advice which one do you prefer?

[fbmcipher]

Thanks @cindmichelle! This is shaping up to look really close to the design. I'm impressed with the progress in the last iteration!

I did still spot some minor spacing inconsistencies though. Take a look at the screenshot below. I annotated all of the spacing issues I could find. The mockup is on the left, and the current implementation on the right. Matching colours pair up measurements that should be equal between the two sides (e.g. green = space between command title and description; red = top of screen to "Gestures" header). These inconsistencies are at the level of a few pixels off here and there, but it does add up.

To share a bit more about my general process with xScope:

My general process is to open the Simulator (iPhone 17) on one side of the screen, and the mockup (in Preview, Figma, etc.) on the other. Then, I line up the top and bottom of the image with the Simulator so they're at equal size.

Compare my alignment in the image above (Simulator and Preview window are exactly the same size) to yours (Figma smaller than the Simulator) – that zoom mismatch propagates into every measurement you take. xScope's guide tool helps here: draw a horizontal guide at the top and the bottom of the Simulator, then scale the mockup to match.

One thing to note: the numbers on my images are only for relative comparison – both Preview and Simulator are zoomed past 100%, so they can't be plugged into code directly. Use them as signals (this gap's too big, that margin's too small), then on your own setup: tweak the code, adjust your measurements, and repeat until your implementation's numbers match the mockup's at the same zoom.

Just those issues, and I think we're ready to send to Raine for review. Thanks for your persistence – I don't want to be too picky, but 1:1 is worth aiming for.

As always, let me know if I can help clarify anything at all!

[fbmcipher]

@fbmcipher in my last commit, i also tried to reduce the padding around the gesture path so we could have more space to render the gesture path. but could you advice which one do you prefer?

I think 9d69f2b is better, because the width of the gesture diagram feels more consistent than in 865320c.

[fbmcipher]

I also noticed that you already enabled the spacing indicators in Figma. It’s been really helpful for implementing the spacing based on that, because earlier I was having a bit of difficulty implementing the spacing since I couldn’t inspect the distances properly. I hope we can also have this indicator for all components!

Interesting, I didn't change anything! I'll try and figure out what changed, so that you always have access to these measurement tools going forward.

[fbmcipher]

One thing worth mentioning though is the GestureDiagram behaviour, as I’m still struggling to make the sizing and display match the mockup exactly due to the SVG aspect ratio being preserved.

As a result, gesture paths with a width/height ratio 1:2 (e.g Select Between) and 2:1 (e.g New Subthought) are ended up being displayed smaller compared to other gesture diagrams with a 1:1 ratio. Do you think this behaviour is acceptable?

Yes, that's acceptable for now. We should tackle that in a separate PR to manage complexity.

[fbmcipher]

In addition to my comments above, a couple other notes:

All gesture titles should line up

The title for "Command Universe" is slightly misaligned with the rest of the gesture titles. This might be because its GestureDiagram is slightly narrower. The simplest way to solve this problem, without touching GestureDiagram, would be to enforce a fixed width for the first column of each gesture.

Extraneous space between top of screen and Gestures header in Capacitor (red line in my image)

Look at the comparison image I posted today – the red line is a lot longer in the Simulator than in the mockup. I think this might be something to do with the status bar area. Capacitor lets us render underneath the status bar area (the viewport fills the entire screen, even the portion occupied by the status bar), and there might be some conditional padding/height displacement somewhere that avoids that status bar area.

[fbmcipher]

I know there is a conversion effort to rem underway, so to save us some work later we should probably use rem units instead of px.

(If you're using AI, you could use a quick prompt to save some time!)

[cindmichelle]

@fbmcipher sounds good. But I want to confirm again whether the font sizes in the design are already finalized, so I can convert them to rem based on the current design?

e.g. Gestures text with font-size: 16px → 0.89rem (since 1rem is 18px by default), and the Gesture command title font-size: 17px → 0.94rem.

[fbmcipher]

@cindmichelle Yes, the font sizes look good to me.

[cindmichelle]

All gesture titles should line up

The title for "Command Universe" is slightly misaligned with the rest of the gesture titles. This might be because its GestureDiagram is slightly narrower. The simplest way to solve this problem, without touching GestureDiagram, would be to enforce a fixed width for the first column of each gesture.

@fbmcipher do you mean the Cancel gesture? I don’t see any misalignment in the Command Universe title, but I can see a slight one in the Cancel gesture

[fbmcipher]

Hi, it's been a while but yes, I think so.

But I would focus on the general issue, not any specific command – in general, it's important that all command titles line up all of the time.