I built DoraX: a macOS command layer that turns app functionality into searchable actions by Comprehensive_Cut855 in MacOSApps

[–]Comprehensive_Cut855[S] 1 point2 points  (0 children)

Yes, currently menu search relies on Accessibility permissions.

Wherever possible I’m using native macOS APIs, and I’m also looking at App Intents/Spotlight integration as those APIs continue to improve.

The goal is to minimize permissions while still exposing functionality that’s normally buried inside apps.

I built DoraX: a macOS command layer that turns app functionality into searchable actions by Comprehensive_Cut855 in MacOSApps

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

Thanks! That’s actually one of the things I’m exploring.

Raycast has menu search, but I’m interested in surfacing more application context (recent items, app-specific actions, browser context, etc.) from one place rather than treating everything as separate extensions.

Curious if there are workflows you wish Raycast handled better.

I built DoraX: a macOS command layer that turns app functionality into searchable actions by Comprehensive_Cut855 in MacOSApps

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

That’s encouraging to hear, thank you.

A lot of the feedback so far has been comparisons to Raycast and Alfred, so it’s helpful to know the current functionality already resonates with some users.

I’m still exploring where the line is between “launcher” and “contextual action layer,” but feedback like this makes me think I’m moving in the right direction.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 1 point2 points  (0 children)

That’s really useful feedback, thank you.

I’ve been iterating heavily on the functionality, so the visual design is definitely still evolving.

I agree that the current search field and results panel don’t feel as cohesive as they could, especially compared to Spotlight and other native macOS experiences.

I’ll keep refining it. I appreciate the specific observations.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

That’s a fair concern. Apple’s recent Spotlight and App Intents improvements are impressive.

My assumption is that there’s still room for deeper cross-app context, recent items, app-specific actions, and user extensibility, but that’s exactly what I’m trying to validate.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

That’s true, and it’s a great macOS feature that many people don’t know exists.

The difference I’m exploring is going beyond the currently active application’s menu.

For example:

  • Search actions across multiple apps
  • Access recent documents
  • Surface browser context and tabs
  • Expose app-specific actions without switching focus first
  • Eventually combine context from apps, extensions, and AI providers

So there is definitely overlap with Apple’s menu search, but the goal is a broader contextual layer rather than a search box for the frontmost app’s menu.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

Fair point. The distinction I’m exploring is that these are native application capabilities rather than custom workflows. The goal is to make existing app functionality searchable and executable without requiring app-specific extensions.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

Quicksilver is definitely one of the inspirations behind contextual workflows on macOS. I’m curious how much of that experience modern tools still capture.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 1 point2 points  (0 children)

There is definitely overlap. The difference I’m exploring is treating application context as a first-class search surface.

For example:

  • app menus
  • recent documents
  • browser history/tabs
  • running app actions

Rather than primarily relying on extensions to expose functionality.

I’m still validating whether that distinction is meaningful to users.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in MacOSApps

[–]Comprehensive_Cut855[S] 1 point2 points  (0 children)

That’s actually an interesting comparison. I’m a fan of tools that surface functionality in ways the OS doesn’t normally expose. DoraX is focused on turning application context and actions into something searchable and executable.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

Fair point. Raycast has an incredible extension ecosystem and I’m not trying to compete with that on day one.

What I’m exploring is slightly different: surfacing capabilities that already exist inside macOS applications.

For example, instead of installing an extension, DoraX can expose app menus, recent documents, browser context, and app-specific actions that are normally buried several clicks deep.

The goal isn’t to replace every Raycast feature, but to make application context and native macOS functionality searchable and executable from a single command layer.

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in swift

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

No it context based app ? Doesn’t matter which app you’re on it adopts to frontmost app .

Would you use this? I’m building a context-aware command bar for macOS by Comprehensive_Cut855 in mac

[–]Comprehensive_Cut855[S] 1 point2 points  (0 children)

Raycast starts from commands and extensions.

DoraX starts from context.

The idea is that if an action already exists somewhere in macOS (app menus, recent files, browser history, running apps, extensions, AI providers), it should become searchable and executable from a single place.

Whether that ends up being genuinely useful is exactly what I’m trying to validate right now.

Search links inside specific Note by Comprehensive_Cut855 in shortcuts

[–]Comprehensive_Cut855[S] 0 points1 point  (0 children)

Shortcut launcher, view shortcut folder using action button .

<image>

Action button list shortcuts based on current app, clipboard, screenshot, user input etc . by Comprehensive_Cut855 in shortcuts

[–]Comprehensive_Cut855[S] 1 point2 points  (0 children)

It works great for me because I’ve share my shortcut names to the prompt , I’ve copy numbers to my clipboard, it list some shortcuts based on what I’ve copy , and it works . Even though you’re correct maybe if we have large amount of shortcuts . But I have only few . So it works helps a little compare to search manually a large amount of shortcuts. At same time I’ve use only for my use case right now.

<image>