a-ve

I've been using deepseek-v4-flash as a "worker" model with Claude Code to implement a tool using Rust/Iroh for my personal use, and it works fairly nicely when I use Opus as the planner/reviewer model. It seems to follow the plan generated by Opus, albeit with a few misses here and there that it cleans up later after being reviewed by Opus.

Fairly excited for the v4.1 launch. Input cache hit prices have been halved, which looks nice.

Thanks! I'll be hanging around this thread for a few more hours. Let me know if there's any feature you need or any bug you encounter.

I reckon peeking into the individual iTerm/Brave/Chrome tabs would not be possible without disabling SIP. I need to research this a bit though.

OP here - I think I need to focus more on accessibility features in the next few releases. Could you please post a screenshot of how boringBar looks to you right now?

Hey, thanks for purchasing it!

I'll take a look into the app launcher issues that you are pointing out. The drag and drop feature will be implemented later this week in the bar window list and in the app menu as well.

I'll research a bit into the offline activation methods as well to see what best suits this app.

I'm able to reproduce the cmd+a issue. Will fix it in the next update. Thanks for letting me know.

The hitbox part is being requested a lot. It'll be a part of the next update too.

Clicking on the chip and not having the window come to the foreground is a fairly weird issue. Do you have anything else installed that uses Accessibility permissions?

On the other observation, it works this way because apps on macOS do not usually quit when you close all of their windows. If you start an already open app again when it has no windows open, it will bring the app into focus, and you will see it in the menu bar.

Regarding your recommendation, I think I’ll need to experiment with it a bit, since it’ll be important to differentiate between pinned apps and apps with no windows in the bar.

Hey! Thanks for checking it out. Regarding your feedback:

- This has been said by another user as well. I am on a 4K monitor - if possible could you share a screenshot of how it looks like currently?

- That's a fair ask. I will take a note of it.

- Drag and drop is something I am working on as well. It will be released in the next version of the app.

- Again, fair. I think I got used to it because I've been using it for a while. But this is being worked on as well and will be released in the next version.

- Ability to give a desktop a name is easy enough. I'll work on this.

- Ability to map a key or sequence for the app menu - you can already do this from the boringBar settings: Just right click on the empty space in the bar and select settings. You can then record a shortcut there.

Regarding the first bug: I do not have a fix for it yet, but I am trying to reproduce it as of now.

I'll try to reproduce the second one as well - this shows up if you are trying thumbnails for the first time - but only just one pop up and not this many.

I think that's fair.

My use case is fairly simple: I usually have multiple VS Code windows open at the same time and I have a habit of moving windows related to a certain task to a specific space. The default Dock mixes every window up and I just want to offload the which-window-is-where tracking to some other app - in this case boringBar.

I tried Sidebar, uBar - all of them. All of them have the same set of issues that they don't take care of windows that are being maximized (they end up behind the bar) and they have intermittent issues with waking up from sleep.

boringBar does not suffer from these issues. That's the reason why I built it. It works as expected from day 1.

Hey. OP here - which part of boringBar did you find slow? Is it the time it takes to hover on a window to show its thumbnail? Or is it something else you think needs improvement?