Workspace Bar Redesign #136
Replies: 3 comments 12 replies
-
|
Personally i don't really need that advancement. Something small that adds to the macos built in bar is good enough for me. There are plenty other of bars and widgets out there and i'd rather have OmniWM focus on the window management - this is where it's truly unique! |
Beta Was this translation helpful? Give feedback.
-
|
For instance Sketchy bar |
Beta Was this translation helpful? Give feedback.
-
|
Agree with this perspective |
Beta Was this translation helpful? Give feedback.
-
|
Yes. I think OmniWM can provide CLI tools and event to interacte with sketchybar is enough. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @xbunax. Omni can have a CLI and emit events that other applications like SketchyBar or BetterTouchtool can plug into. Additional if Omni gets designed around a plugin ecosystem then it will ease the maintenance burden. Maybe the workspace bar can be migrated to a Lua plugin that users can see as an example of how to consume events? Plugins could then be toggled in the menu bar and have keyboard shortcuts assigned to them. I think keeping window management as the core feature and adding new features as plugins going forward is the most sustainable approach from what we have seen in open source. |
Beta Was this translation helpful? Give feedback.
-
|
not inherently against the idea of a full bar replace, but it seems like that would be better suited for an additional 'OmniBar' application - with good integrations and support for OmniWM. From my own experience, originally coming from AeroSpace + Sketchybar, having a Lua api for the bar would lessen the friction in adopting only OmniWM. You can swap out aerospace and still retain your existing bar (that people have no doubt put additional time and effort into). Though at that point, you're just re-inventing Sketchybar. Are there specific fmissing eatures within apps like sketchybar that 'OmniBar' would support? |
Beta Was this translation helpful? Give feedback.
-
|
That's awesome, looking forward to giving it a go once I get a break from work and can risk going back down the rabbit hole of optimizing my setup :P I'm curious, are there any APIs available to integrate OmniWM with my own custom Sketchybar? is there any documentation page other than the main README in the repo? Thanks again for your hard work, if I adopt Omni as my primary WM going forward I'll sure become a gh sponsor |
Beta Was this translation helpful? Give feedback.
-
|
@santip No cli/ipc is planned at all. Omni strives to be an all in one Linux WM experience for a macOS that is opinonated while still allowing users some sane customization. As for documentation, it's mostly there but I am kind of lazy keeping it always updated due to rapid development, never the less it's very easy to customzie and set it up due to GUI settings which make massive documentations kind out outdated experience for a user. |
Beta Was this translation helpful? Give feedback.
-
|
Im also voting for a cli. maybe that's because im used to other tools ive used more or less requiring a cli for my workflows, but I've already found a few (very small, but still..) missing pieces, like for example:
adding features like this to a config GUI would be quite painful because others would prefer a similar but slightly different configuration... by adding a cli that basically let's us query the windows + trigger any bindable command is (I assume) an easier route than trying to cater for all the feature request that will surely get posted :) Is there a specific reason for not adding a cli, or is it because you simply don't want to spend the time on something you don't see a need for? I would be happy to contribute if you're open to the idea! |
Beta Was this translation helpful? Give feedback.
-
|
@sebb3 The reason why at least for a forseeable future I don't want to add is multipel of reasons:
The example you gave is understandable but implementing it would mean needing a lot of information to be tracked and opened up to the cli while still maintaining everythign, as OmniWM has true monitor synced refresh rate animations (no tricks, just pure true animations), borders, a very complex layout compared to i3 type layouts, bunch of UI and extra features and all of them have to be tightly optimized to avoid race conditions while preserving responsivness. But if you are willing to give it a go and maintain the issues related to it while keeping up with rapid OmniWm changes I don't midn and would appreciate it ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
@sebb3 if you can take on adding support for a cli or alternative api, I'd be happy to try to assist with maintenance in the future. I don't have experience developing on swift but I'm happy to learn in the process. @BarutSRB I'm noticing a few bugs with windows sizes in certain situations and specially with the borders staying out of sync (this is on Tahoe), do you want me to create an issue for it or is this something you're aware of already? |
Beta Was this translation helpful? Give feedback.
-
|
I’ve started working on a prototype for a cli, and currently trying it out locally. Trying to write in a way that minimizes maintenance, basically just exposing all the HotkeyCommands and adding a few cli-specific commands such as querying windows and targeting a specific window instead of just the focused one.
I think I can create a PR within a week or so.
…On 21 Mar 2026 at 18:40 +0100, Santiago Perez ***@***.***>, wrote:
@sebb3 if you can take on adding support for a cli or alternative api, I'd be happy to try to assist with maintenance in the future. I don't have experience developing on swift but I'm happy to learn in the process.
@BarutSRB I'm noticing a few bugs with windows sizes in certain situations and specially with the borders staying out of sync (this is on Tahoe), do you want me to create an issue for it or is this something you're aware of already?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@sebb3 Thank you Sebastian ❤️🤩🥳 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Even though Omni started out of my frustration with the macOS workflow after being spoiled by Linux environments like Hyprland and Niri, I still see it as a tool shaped by my preferences but ultimately meant for the community. Because of that, I would really value feedback on the design choices and overall direction, especially as I redesign the workspace bar.
I do have a few strict design guardrails:
It must not consume too much screen space
It should improve user workflow first, while still looking good enough for the ricing community
It should remain confined to the status bar area
It must allow users to create and share customized widgets and visual setups
My current idea is to have the workspace bar fully overlay the native macOS status bar. Users could reveal the native bar either through a hotkey or by moving the cursor and right-clicking on an empty area. This is important because, while we often do not need the native menu bar thanks to tools like a searchable command palette triggered by Ctrl+Alt+Space, there will still be cases where it is necessary.
While it is technically possible to replace almost everything, I do not think that is always the right approach. Not everything needs to be rewritten in Rust just for the sake of it nor is it good to do it always. It is similar to rewriting stable CLI tools in a new language purely because it is trendy. Even today, nothing is truly a perfect code, not even assembly written hello world. Many systems still build on ideas from decades ago, including hardware design.
For customization, I am considering Lua. I know it may not be popular with everyone, but in practice it offers a fast, lightweight, non-compiled scripting option that is simpler to integrate than heavier runtimes. Even free basic AI tools can help users write Lua scripts, which lowers the barrier significantly. These scripts would live in a user settings folder within OmniWM. They would not support live reloading but instead be loaded during launch, as I want to keep the scope manageable. More advanced customization can come later, likely before summer.
For now, the focus is intentionally limited. Users will have control over what their widgets do, but less control over how everything looks. I still want a somewhat opinionated visual design, shaped over time by community feedback, while allowing room for useful and creative widgets.
I would really appreciate feedback on this direction. My goal is for Omni to act as a replacement for tools like SketchyBar, while delivering the feeling and visual experience of a Linux window manager, after all there is a reason why it's called Omni if somethign cool pops up and is useful and liked by the community it will get implemented unless its not MIT or GPL licensed but even if it's not open source everything can be replicated as long as it doesn't have a patent for it, and you can count on Omni if community wants something that it will be implemented especially if it is simple yet expensive at least to show the get rich quick AI vibecoded app businessman that they are in the wrong industry for their end goals. Perfect code are not the primary focus, but if anyone wants to refactor to make it better you are welcome, but responsivness is a must even though it might not be in some eyes considered perfomance due to resource usage but Omni aims for user experience not beautiful clean maintainable code over the responsivness or usefullness. The emphasis is on how the system feels to use, especially given that we are working on modern Apple hardware.
Beta Was this translation helpful? Give feedback.
All reactions