We're working on extensions and Adblock right now, so should be out soon!
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.
Try it out and let me know if you think it's necessary to support CMD-W :)
> 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.
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.
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 :)
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!
> 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.
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!)
- Extensions - Adblock - No support for CMD+W (?)