Publish as Community Plugin

[lukemt]

I think it's about time to publish the plug-in for the community. It may not be perfect, though it's already pretty useful.

Any critical bugs or features missing for the release? What do you think?

As far as automated testing goes, maybe we can start by writing down test cases and use them for manual tests. Fully automated testing seems a bit excessive to me (although cool 😎)

[aidan-gibson]

Fuck it we ball 😤😤😤

[aidan-gibson]

I remember there being some config option somewhere to specify DesktopOnly...honestly I think just that and we're good.

Not sure how fully automated testing would work anyway, it's just a bit of a drag to test all the different settings options with every minor change pushed. But I should test everything manually before publishing for sure(:

[lukemt]

Hell yeah!

[lukemt]

Hell yeah! Preparing the Release...

Thoughts on Tab Navigation Behavior

I was thinking, should there be a way to navigate to a different file and replace the current tab, just like the default behavior, for example, by clicking a link? But wait, alt-clicking already has another function, so that might not be a good idea. Someone else suggested an interesting twist – command click to replace a tab, and normal click to open a new one. Honestly, not a fan of that as it inverts the standard functionality, which is kind of weird. For me, I don't miss that feature at all. If I want to replace a tab, I can just open a new one and close the old. Probably, most people installing this wouldn't bother too much. So, my conclusion is, it's fine the way it is, though we might consider this as an optional additional setting or just keep thinking about better ideas.

On Mobile Compatibility

Now, about this mobile thing. Currently, the plugin is desktop-only, and that's cool for now. isDesktopOnly is set in manifest.json already. But you know what? Let's think ahead. We can start by activating this thing on mobile and see how it goes. Maybe, we can implement a feature flag for optional activation on mobile. You could have a setting to switch on. Set to false initially, so manual activation is needed. Yeah, that could be a new feature. We can create a new issue for that, but for now, it's alright to be desktop-only.

On Handling PDF Files

Okay, let's talk about PDFs and other files. I don't use 'em much in Obsidian, but when I do, I'd probably prefer opening them in Obsidian. Although I'd like to have the option of both. So, my preference would be this: When I click on a PDF link, it opens within Obsidian, but in a new tab. But when I command click on the PDF link, it opens in the native app. Best of both worlds!

[lukemt]

Hi @aidan-gibson

when you find the time maybe create a new version :P

[aidan-gibson]

Hi Luke! I'm down for as many options as you'd like. That sounds fine to me. I strongly preferred opening pdfs in Preview prior, but Obsidian has really upped their game with the native pdf reader, so I'm now cool with defaulting to Cmd+Click to open via system default pdf reader.

I'm a bit hesitant to publish to community plugins while #23 is still looming large, but pending that bug getting squashed I'm ready to roll.

[aidan-gibson]

@lukemt I sent you an invite as a collaborator btw! Sorry I didn't do so earlier, I've never done this before and wasn't sure how it worked.
To trigger the github action for new releases, after making commits, you do the following
npm version patch -m "<version message here>" && git push origin --tags && git push (I know the extra git push is totally cringe, haven't had time to uncringify it yet lmao). Thanks again for all the time you've put into this!

[lukemt]

perfect!