> For CMD-W, we're trying to change how you think about pages to something you "mark as done" as opposed to just "close", and changing the shortcut helps make that change for users.

Please don't force users to un-learn years of what they already know. It doesn't matter if you call it "closing" a page or "marking it as done" but _please_ make well-known keyboard shortcuts do roughly what a user would expect.

We definitely don't want to punish our users or make the app feel worse.

We're testing out a classic mode at the moment that allows your current shortcuts to work as well :)

You can change what happens when a user hits CMD-w. But CMD-w should still be the trigger.

Everyone expects a very specific thing, make the current thing go away. Its the same reason you likely picked CMD-k as the shortcut to your pop up window. That's what Slack does along with several other applications.

If you want to map this shortcut to your implementation of "going away" that's fine but it should be the same command.

This is a fair point.

Right now, it shows a message on the bottom-left asking if you meant to close a page and suggesting "D" as the shortcut instead.

I think adding a classic mode with those shortcuts enabled should solve the issue. What do you think?

What happens when a user thinks they are in an input field and hits 'd'?

I've experienced the likely same outcome with Vimium and 'x'

I suspect you will want to have modifier keys be the default. Something to ask users rather than forcing them to adopt to what you think is best

Hmm, I want to look further into how often this happens. Was this a big issue for you with Vimium?

Right now, if you accidentally close a page, you can quickly "Z" (or click the undo button that shows up) to bring the page back.

I've experienced the loss of input when I habitually hit escape to exit input mode and then x to delete text. (Normal on vim, does not carrier over the same with Vimium)

This closes the tab, and on restore, the partial input is lost. Had this hit me more than once on Confluence

Good point. Currently though, if you "z" a page you've closed, it preserves your input. The system isn't perfect, but it prevents any fear of accidental closing.

Can't comment on your browser specifically, just that single key shortcuts which are normal input values is not a good idea. People are used to shortcuts with meta keys proceeding them. It's an established behavior and expectation beyond any one system or tool.

Yeah, it's something we thought about a lot before implementing the current system.

We think apps like Superhuman have brought the idea of single-key shortcuts into the forefront, and we really like how much more memorable they are for most users.

We'll definitely learn from our users' feedback though, and we'll work on a solution with them if they have issues with it :)

Are you planning to adopt an existing browser extension API or will extensions need to be rebuilt for Sigma?

I'm working on building it from scratch for SigmaOS :P. Should have it out in a couple weeks!

edit: implementing Chrome extension API. All Chrome extensions will be available :)

What made you decide to build it from scratch? By following a different system you're leaving a lot of free work on the table. For example, I extensively use Vimium, Dark Reader, Stylus, TamperMonkey, and LastPass. By doing it from scratch, all of those extensions would need to be re-implemented in the SigmaOS API. I love the idea of SigmaOS but I can't abandon Chrome/Firefox if I can't have LastPass, for example.

Whoops, I might have not explained myself properly. I'm implementing the Chrome extensions API from scratch. When I'm done, you'll have access to all of your Chrome extensions!

Oh perfect. Thanks! Great work on the project by the way

Thanks!

> We're working on extensions and Adblock right now, so should be out soon!

Do you find that your decision to use WebKit is getting in your way here?

As it happens, my company is also working on a browser for a niche userbase (not competing with you!), and I decided to go with Electron rather than Microsoft's WebView2 because it seemed to me that that option would give us more flexibility to deeply customize both the chrome and the content. Our target user base is mostly on Windows, not Mac, so Apple WebKit wasn't on the table for us.

Hmm, not familiar with WebView2 myself.

I think WebKit helped a lot initially getting everything running. Not having access to extensions and other limitations imposed by Apple is a bit of a bummer (which I'm working around), but I think it's been much better than using Chromium/Electron still (especially on performance!)