microsoft / microsoft/PowerToys
Proposal: OmniTray - drag, drop, stack, and shelf anything
- Dominant language
- C
- Stars
- 139k
- Forks
- 8.6k
- PR merge metrics
- PR metrics pending
Description
### Description of the new feature / enhancement
_Disclaimer: Toaster proofread this text, which means it probably made random changes to it..._
Drag Tray was removed from Windows. Omni Tray is a proposal to revisit that interaction as a more general, extensible drop surface.
OmniTray provides edge-hosted trays (shelves) and floating trays (droppads) containing two kinds of targets:
- **Stacks**, which persist[^1] and organize dropped content.
- **Drop commands**, which perform actions such as opening an app, running a script, or moving a file.
Shelves reveal themselves when a drag begins. Individual stacks can also be popped out into standalone windows for persistent access.
The initial prototype focuses on creating and updating stacks from clipboard contents. The broader design covers direct dragging, edge windows, virtual stacks, system integrations, and out-of-process extensions.
https://github.com/user-attachments/assets/cdfb0bbe-37ae-4006-80e8-c843f9467ba0
### Prototype
Prototype: https://github.com/jiripolasek/omnitray
### Pitch
Expand the full design pitch
## The cardinal rules
1. Drag it.
2. Drop it.
3. Stack it.
4. Shelf it.
5. Pop it out.
Drag Tray was removed from Windows. Sob, sob.
Now we get to replace it with something better.
---
## 1. Drag anything
Dragging is the trigger.
If the user can drag something—and we can meaningfully persist it or pass it to an action—they should be able to put it in OmniTray: an image, plain text, formatted text, music, a file, a link, or whatever comes next.
### The first usable version
The MVP starts with the smallest complete version of this interaction: moving content from the clipboard into a stack.
- Create a new stack from the current clipboard contents.
- Add the current clipboard contents to an existing stack.
This establishes the core content and organization model before taking on every drag source, edge interaction, integration, and extension point.
### Reveal on drag
When the user starts dragging, a shelf hidden at the edge of the screen should peek out—perhaps by 48 pixels—to show where they can drop what they are carrying.
This visible strip is a dedicated drop affordance, not a cropped view of the shelf itself. It should show a clear icon or illustration inviting the user to drag over it.
When the pointer enters the revealed strip, the rest of the shelf slides out and exposes its contents and drop targets.
---
## 2. Drop it
What gets dragged has to be dropped. There are three reasons to drop something:
- To collect it.
- To reuse it in a moment.
- To do something with it right now.
### Drop commands
Not every drop target keeps what you give it. Some do something with it.
A drop command is an action presented as a drop target. Drop an item onto one to open an app, run a script, move or copy a file, or perform another immediate operation.
Unlike a stack, it executes an action instead of saving the dropped item.
Extensions define configurable command templates. Users instantiate those templates, supply their parameters, and add the resulting commands to a shelf.
Stacks remain flat, but drop commands may be organized into folders:
- Image tools
- Crop
- Rotate left
- Rotate right
This lets extensions provide families of related actions without turning the stack model itself into a hierarchy.
---
## 3. Stack it
One thing is rarely enough. We need a simple way to group related things.
Looking at the mess on my desk, the answer is obvious: stack them.
A stack is OmniTray’s main unit of organization. It is not just a container—it has an identity of its own: a name, a color, and perhaps an icon.
It should be recognizable wherever it appears, whether it is sitting on a shelf or popped out onto the desktop.
### Virtual stacks
Not every stack must own its contents. A virtual stack can expose items backed by another live source, such as:
- Clipboard history
- A filesystem folder
- An extension-provided source
### Editable items and provenance
Captured text should remain editable. A text entry without external backing can effectively become a sticky note.
For other non-backed entries, OmniTray should preserve their provenance when possible—for example, the URL of the page from which an image was copied.
---
## 4. Shelf it
Once you have stacks of useful things and commands that do useful things, you need somewhere to keep them.
The old Drag Tray was loved because it stayed hidden at the edge of the screen until you needed it. Let’s bring that idea back—and make it better.
Every edge can be a shelf.
### Horizontal and vertical layouts
Horizontal and vertical shelves have different constraints and should use purpose-built layouts. A vertical panel should not simply be a horizontal shelf rotated by 90 degrees.
Their proportions, scrolling behavior, item presentation, and use of available space will differ by design necessity.
### Edge windows: simplicity versus customizability
Edge shelves need enough flexibility for different workflows without becoming miniature window managers.
A reasonable starting model is:
- At most one shelf per edge.
- Users organize multiple stacks and commands inside that shelf.
- Each edge can be enabled or disabled independently.
- Shelves open to a moderate, configurable size by default.
- A full-edge mode can be considered for denser setups.
- Shelves behave as overlay windows and do not reserve desktop work area.
AppBar-style docking could be explored later as an optional persistent mode, but it should not define the initial hidden-shelf experience.
### Reusing CmdPal UI
We should investigate whether shelves can reuse or host CmdPal list pages.
This could allow existing extensions to expose content through OmniTray without requiring another parallel UI model.
---
## 5. Pop it out
When I am actively working with something, I want it close at hand.
Pop a stack out into its own window: persistent, immediate, and delightfully utilitarian—like the old drop pads, back when window chrome was gray and square.
---
## Central hub
Separate edge windows need a central place for management.
The current prototype uses a system-tray popup as that hub, which works well for quick access.
A dedicated manager window could take over—or complement it—if organizing shelves, stacks, commands, and extensions becomes too complex for a popup.
---
## System integrations
Potential integration points include:
- A shell extension
- A Windows **Send to** destination
- Browser extensions for capturing pages, selections, images, and source metadata
- A Windows Widgets extension
- A CmdPal extension
- Windows Search integration
---
## Extension architecture
One possible direction is a Native AOT-compatible extension model built around COM contracts and out-of-process extensions.
Extensions could provide virtual stacks, drop-command templates, content sources, and system integrations while remaining isolated from the main application.
### What I’d love feedback on
- Does revealing shelves when a drag begins feel useful and discoverable?
- Should there be at most one shelf per edge, or should multiple shelves be able to coexist?
- Should shelves use a moderate fixed area, a configurable size, or the full edge?
- Is an overlay the right model, or would an optional docked/AppBar mode be valuable?
- Does clipboard-to-stack feel like the right first usable version?
- Which content types, drop commands, and system integrations would be most useful?
---
[^1]: Long time ago, in Edge version far, far away: https://support.microsoft.com/en-us/edge/organize-your-ideas-with-collections-in-microsoft-edge
Contributor guide
Assessment
This issue has not been assessed yet.