menu: make menu items be disabled not disappear/reappear

[mimecuvalo]

Alternatively, we add a separate menu if we feel that this menu has too many items in it. I'm thinking perhaps an "Object" menu, the way that Inkscape, say, has.

Before

After:

Change Type

• [x] patch — Bug fix

Release Notes

• Menu: update Edit menu to be more consistent in its available options.
• Menu: create an Object menu

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
examples	✅ Ready (Inspect)	Visit Preview	Feb 20, 2024 5:07pm

1 Ignored Deployment

| Name | Status | Preview | Updated (UTC) | | :--- | :----- | :------ | :------ | | **tldraw-docs** | ⬜️ Ignored ([Inspect](https://vercel.com/tldraw/tldraw-docs/BjZeqBPkuYiaBAMErZyN1gXVGFup)) | [Visit Preview](https://tldraw-docs-git-mime-edit-menu-tldraw.vercel.app) | Feb 20, 2024 5:07pm |

[SomeHats]

What's the thinking here?

I'm unsure about this change because at the moment, the edit menu is set up to mostly emulate the contents of the context menu because it's often easier to access on mobile (long-press is annoying). Because of that, it potentially contains a lot of our most weird/obscure context-specific features - e.g. converting embeds to bookmarks & bookmarks to embeds. These only show in the context menu when they can actually be applied - when a single one of the correct shape is selected.

I don't think these very obscure shape specific options should always be in the edit menu - they're very rarely relevant, and I think would be a distraction to most users. Of the ones you've changed here, group & ungroup are probably the only ones that I think are sufficiently generic that they could have this disabled state instead.

[mimecuvalo]

@SomeHats yeah, great points. I think that speaks then, and makes me lean towards the alternative option mentioned in the description: we should just a separate menu called "Object". That would match more the paradigm of other drawing apps and would make the Edit menu feel less like a kitchen-drawer of some random things.

[mimecuvalo]

@SomeHats and @steveruizok if that sounds good - I'll rework this PR to make an Object menu!

[SomeHats]

I don't feel super strongly about edit vs object, but my gut feeling is that there isn't a tonne of meaning to differentiate between edit & object and i'd rather have a long scannable list of options (minus noise like 'bookmark -> embed') than multiple menus i have to dig around in.

what is the actual intention here? is having these options hidden rather than disabled a problem?

[steveruizok]

Let's wait on this, there's some intent in the current design that may be missed in this PR. Generally our rule is "disable in the menu (for discoverability) but hide in the context menu (because real estate is at a premium)"

[steveruizok]

(Not opposed to an object menu; at least let's land the composable UI PR first to avoid ugly conflicts)

[mimecuvalo]

Generally our rule is "disable in the menu (for discoverability) but hide in the context menu (because real estate is at a premium)"

yeah, that's what this diff is trying to solve - the menu items are being hidden instead of disabled in the menu.

i'll wait til the composable stuff lands!

[mimecuvalo]

@steveruizok @SomeHats PTAL

[SomeHats]

Some thoughts:

• Select-all should be in edit, not object
• Copy-as should be with the other copy-ish things in edit. Export-as... maybe that too? they feel similar
• Group, ungroup, remove frame, and fit to content should be in a group separated by a line
• Duplicate & delete should maybe be in edit (figma does this) or at least be grouped together
• unlock all doesn't operate on the current selection so it shouldn't be in object probably?

personally i'm unsure about the object menu - it feels hard to make the grouping anything other than a bit arbitrary, so now there are two places to look for a particular option instead of just one. maybe that's fine though?

[mimecuvalo]

great feedback @SomeHats

Select-all should be in edit, not object

done.

Copy-as should be with the other copy-ish things in edit. Export-as... maybe that too? they feel similar

done - i'm mimicked figjam here which puts it along side cut/copy/paste which makes a lot of sense.

Group, ungroup, remove frame, and fit to content should be in a group separated by a line

done.

Duplicate & delete should maybe be in edit (figma does this) or at least be grouped together

done.

unlock all doesn't operate on the current selection so it shouldn't be in object probably?

it should be in Object. figjam puts it in object as well and i would agree.

personally i'm unsure about the object menu - it feels hard to make the grouping anything other than a bit arbitrary, so now there are two places to look for a particular option instead of just one. maybe that's fine though?

the problem is that it just doesn't fit in Edit. Edit has become a grab bag that loses it's meaning. i get that it can feel like one is looking at two places instead of one but we can't just grow Edit ad nauseum to an arbitrary length. we should stick with the industry paradigm here — breaking from that would need a better justification from us on why we would break people's expectations there.