I used to have my daily note open to the side and be able to click internal links which would then open in the main window. It was great. It’s been removed in 2.6.2 and I miss it.
I do find it weird that @matteo apparently marked this behavior as a bug. It’s definitely not ‘changed recently’, it has been the behavior for years, I have come to rely on it, and suddenly in a timespan of two days it gets removed without any alternative
Bug or not, I personally felt that it made a lot of sense to have the distinction between a detached note that would always keep its own window and the ‘main window’ where all the browsing happens. However, I can also see why it wouldn’t be preferable in other cases.
A solution would be to add the option to ‘pin’ a window to prevent that window from navigating away, similarly to how Obsidian allows pinning tabs. Like this, the default behavior will be to have the full functionality in each window, but the user still gets the option to have a pinned window that doesn’t navigate. Hope you will consider adding this and thus restoring a workflow that really worked for me
Please no! The usual paradigm of links, as per web browsers, is to have the link be followed in the window it was clicked in. Absolutely all apps behave that way, from Apple Notes to OmniFocus all the way up to Obsidian; not doing so makes following your thinking extremely difficult. That behaviour was a bug, see Tabs like Web Browsers - #52 by matteo
You can open links in other windows using Cmd-click or shift option cmd K. If you want a quick way to do so, you can automate this with tools like Keyboard Maestro or BetterTouchTool. For instance, I have bound a tap on my Magic Mouse to cmd clic, making opening links in new windows incredibly fast and easy.
Hi Killerwhale. Thanks for sharing your preference. I can see how the new behavior is probably preferable for most users and I’ve changed my request.
Your suggestion to open a link in a new window unfortunately doesn’t work, because it will only open a lot of windows, whereas in my previous workflow I could just switch between the main window and the detached note
Also, the current ‘fix’ is a total mess. New links still open in the main window. Quick Open still opens in the main window. This further leads me to believe that opening links in the main windows wasn’t just a bug. I believe that it was a conscious design choice. Of course it’s possible to make new design choices, but they should be well thought out and implemented and not just thrown in like that without any consideration for current workflows or even the app as a whole.
Bear used to be an app that took way too long to implement new features, but at least they were well thought out and part of a bigger design plan.
Yeah but not in the current detached window you’re working in. But in that window you can open links, because that’s the design, but not new links, because it’s all part of a super consistent design and vision for the app
What I guess I’m trying to say is I’m just sad and mad that a feature that I loved and that’s been there for years (in an app that I really loved and have been using for years) gets flagged as a bug and removed in just a few days time without any thoughtful consideration for how the rest of the app works or how to accommodate users that might be relying on that feature. I get that apps cannot keep every user satisfied, but I also think that as a developer you have some responsibility towards your users in not randomly changing functionality.
I don’t believe we’re talking about a bug. We’re talking about some very obvious behavior that has been there for years and that is also implemented in other parts of the app. I think detached windows were designed as a way to open a note in its own window and not to be navigated in. The fact that you can launch Quick Open from a detached window but the note still opens in the main window, and the fact that new links from a detached note are still opened in the main window are both pointing to that. It was consciously implemented this way. If the developers make the choice towards a different paradigm where basically every window is a ‘main window’, I would still be sad, but I can understand that design choice. But then it should also be thoughtfully considered and consistently implemented.
I’m very sorry that a feature you’ve been relying on has been taken away, but this was very clearly a non standard and undesirable UX. Hyperlinks open in the window where they are clicked, that has always been the model ever since the first web browsers. All apps on the market behave that way, from Notes to even OmniFocus.
And now, having per window browsing history offers the added benefit of solving the longstanding request of having tabs in the app, but using a different model based around separate windows, which the devs seem to prefer.
Ok thanks for repeating your point on how links should behave. I’m not refuting your preferences or even your claims to universality of those preferences. My point is that (no matter how undesirable it may apparently be according to normal human beings) there are quite a few signs that this is how detached windows were designed and that they’ve been working like that for years. If as a developer team you want to change that because all humanity instead of me believes another design is better, you don’t do that by calling random parts of it a bug and ripping them out, you do it by thinking how you want the app to work and then building that behavior. At least that’s the thoughtful approach that I’ve come to know from Bear
Sorry it took a while to get back to you, things have been pretty busy lately!
First off, I’m really sorry if the new behavior negatively impacts how you use Bear. When I called it a bug, I didn’t mean to downplay your use case or its importance.
Here’s the situation:
The “open links in the main window” behavior was how Bear 1 was designed. With Bear 2, and the introduction of history buttons, we decided to let detached windows have their own history and open links internally. We use callback URLs internally, and after the big Bear 2 rewrite, it seems the open-note xurl started using the note UUID instead of the origin window UUID, which broke the intended behavior (hence the bug).
Detached windows are a pretty niche feature, so this went unnoticed until @KillerWhale pointed it out. At first, I thought it was a simple fix, but as you mentioned, I didn’t fully grasp the complexity. It looks like the create xurl might have the same issue and doesn’t correctly account for the originating window UUID.
As for QuickOpen, that’s a bit different. It’s designed to always open in the main window since it can handle more than just notes (like tags, locations, and potentially more in the future). Detached windows just can’t support all of that.
Honestly, this all started because I thought it was a quick and easy fix (story of my life ), but it turned out to be more complex than expected. I should’ve brought it to the team for a deeper discussion earlier and that’s on me.
We’ll have an internal chat about this and figure out the best path forward.
Thanks for starting this discussion and helping us catch it!
Thanks for explaining Matteo. It’s good to know that this is indeed how detached windows were designed in Bear 1 and that you’ve been intending to move towards a different functionality in Bear 2 which (if I understand correctly) never actually happened until now. Also thanks for discussing this internally. I hope you can come up with something!
), but it turned out to be more complex than expected. I should’ve brought it to the team for a deeper discussion earlier and that’s on me.