Originally posted by **SimHacker** June 4, 2024
I think tldraw would make the ultimate pie menu editor.
It could use a well thought-out set of default pie menus for its various editing commands and built-in shapes, of course.
But beyond that, users should be able to easily define and edit their own custom graphical pie menus by direct manipulation, using the full power of tldraw to define the presentation and interaction.
One useful application for user defined pie menus is arranging your own custom library of shapes to "pull out" and place into drawings.
Pie menus can use the distance from the menu center as a parameter that modifies the selection, for example, the further you pull out, the bigger a shape you get, and it gives you feedback of exactly what the shape you'll get will look like as you perform the stroke gesture.
World of Warcraft and other games let players arrange bags and chests in arbitrarily nested trees, and lay out their various items in the different chests, categorizing them and grouping them in memorable patterns and layouts. Much like a directory tree of file icons with two-dimensional coordinates, that users can arrange any way they want. But that would be even better if it supported gestural pie menu navigation.
You could define your system-wide pie menus as a separate tldraw document, or document-specific pie menus in another page of the document.
So if you're producing a comic, you can make a navigable pie menu library of your characters, poses, expression, objects, decorations, speech bubbles, etc. And pie menus are a fun way to arranging and navigate personal libraries of commonly used emojis, expressions, gifs, and memes, for messaging and chat.
Here's a model for building pie menus, nicer than modeling them as a menu containing items (like linear menus): you model them as a top level "pie pan" (a container that can have a shape -- a big circle or pretty flower or geometric octagon or brutalistic square, etc -- or simply be invisible). The pie pan contains a fixed number of "pie crust" slices (one or more of which can be empty/null to show through to the background or previous super-menu), and each slice can contain zero or more "pie filling" items. (The culinary metaphor breaks down a bit, but the point is to use pie/slice/item instead of pie/item).
The reason for that is to let the user set the number of slices BEFORE adding any items to the menu, so the directions are stable as you add items by dragging them into the stable slices, one by one. Also to support slices with zero items: inactive dummy placeholder slices. So if you have seven items, you can have an empty slice without any items to bring the number of items up to eight, to make it balanced. Because 4 and 8 and 12 item pie menus are much easier to use, learn, and remember than, i.e. 5 or 7 or 9 or 11 or 13 items (odd, less symmetrical) pie menus. Both physically articulatinng the vertical/horizontal/diagonal gestures, and mnemonically remembering the compass directions, clock face hours, etc. Also slices can contain multiple items that you can select between either by "pulling out" further, or pointing at multiple targets, rings, labels, icons, etc.
In tldraw, the pie pan would be like a frame, but round or clipped to an arbitrarily shape. (See the "Clipped Groups" proposal: https://github.com/tldraw/tldraw/discussions/3866 ). The pan can contain a number of crust slices, like sub-frames, wedge shaped pie slice target areas, with a small round central "inactive region" cut out. The pie menu pops up centered with the cursor initially in that inactive region, so you have to move far enough to exit the inactive center and enter one of the slices, or just click again in the inactive center to dismiss the menu. Each slice can contain an arbitrary number of items placed wherever you like, which can be configured to select with either radial pull-out distance and/or 2d target shape.
It's also useful to have extra help text and graphics that is incrementally revealed ("progressive disclosure") when you point at or pull out an item with a detailed description, so you can show the description of the currently selected item after the user hovers in it for long enough (or instantly -- it should be configurable). Pie menus let you browse around and reselect different items, correct mistaken gestures or change your mind before finally selecting an item, or cancel the menu entirely.
Another nice touch is to animate the currently selected item to the cursor, expanding the indicated item in details and size, and follow the cursor around with it, snapping back to its default location and size and detail when you indicate another. The cursor is where the user is usually looking, so bring the item to the user's eyes, instead of requiring their eyes to jump around between the cursor and the items.
These pie menus that I implemented for Unity3D demonstrate some of these features, like moving the items to the cursor, and defining and directly manipulating the menus and items as in-world objects (they're 11 years old so the code is not very up-to-date or modern by Unity3D standards, but there's a link to the source in the description):
https://www.youtube.com/watch?v=sMN1LQ7qx9g
Another goal is not only to implement user-editable pie menus for tldraw, but also as stand-alone React, SvelteKit, HTML components, etc, so you can export the pie menus you define in tldraw as JSON+SVG, and run them in non-editable mode in other apps. Then other apps could embed tldraw to enable users to edit that app's pie menus, as well as any other graphics.
So not only does tldraw need good pre-defined pie menus for itself, and user editable pie menus for its users, but I also think it's useful for other apps to have light-weight non-editable runtime pie menus defined in a portable enough format that they can be used by many different implementations that share the same format, that tldraw can export, and you can use or even embed tldraw to edit the menus for those other apps.
linear[bot]
commented
1 month ago
Discussed in https://github.com/tldraw/tldraw/discussions/3867