Hi, Kenneth here from Stripe. I'd love to chat with you about the problems you have with webhooks. How can I best reach you? My email is auchenberg@stripe.com
:wave Kenneth here. Linux support is on the roadmap, and can be supported via https://libimobiledevice.org/ but not all functionality might be possible, as libimobiledevice isn't 100% on pair with Apple's own driver that's provided via iTunes on MacOS and Windows.
Would love to get some help testing this as I'm not a Linux user myself. Shoot me an email at kenneth@auchenberg.dk if you are interested!
We have looked into this, and haven't found an intentional change that should change your opt-out settings. This shouldn't happen.
We have two theories:
1) Your settings file was deleted, which means that you would have lost all of your settings, and not just the telemetry setting. This can happen if the AppData or ~/Library/Application Support was cleaned up.
2) One of your installed extensions updated the settings either accidentally or on purpose. This would require further debugging, and a list of your installed extensions.
To help debug this further, it would be great help if you could open an issue on Github, https://github.com/Microsoft/vscode/, with more details about your OS, VS Code version and installed extensions, so we can figure out what happened.
Hi, I'm Kenneth, PM on VS Code. To clarify here: @code is written in TypeScript and is an Electron app. Not React Native. We don't have plans on moving away from Electron in any near future.
Chrome DevTools Protocol (CDP) is a more advanced API, and I've been leading an effort on getting multiple browsers to look at CDP under https://remotedebug.org
Agreed. This is much needed for enabling other tools to be built in the RemoteDebug-ecosystem.
I've recently started exploring what I could mean to have concurrent connections to browsers, and what kind of tools we could build. Realtime visual comparison is really exciting.
I completely agree. There's still a long way until we have a common API that caters for all use-cases across tools and runtimes, but uniting around the same protocol is the first tiny step towards this vision of better decoupled tooling.
Luckily the Chrome Remote Debugging protocols is quite flexible, so we could start iterating on the API's too using some sort of vendor prefixing, if needed.
No that's not what I'm saying in my post. A browser choice on iOS wouldn't make Safari go away, and wouldn't mean that developers shouldn't cater for mobile Safari.
But it would give us the option to deliver experiences for other browsers, that might lead to better and more innovative experiences for our end-users. We don't know, because we don't have the choice.