Open JSTee787 opened 3 years ago
You know, this isn't a bad idea, but maybe we should turn it around. Rather than adding a setting to start with the shader disabled, and then use toggleShaderEffects
to enable it, what if we let toggleShaderEffects
accept a path
parameter? Then you could press a key and enable one shader, then press a different key and enable a totally different shader. Then, the profile wouldn't have a shader set in it's own settings, but the keybindings could apply to any profile.
Ok, I like that idea, in addition toggleShaderEffects would have to have some means of specifying that pixel shader should be turned off, either "null" or an empty string for the path (I'm not sure what best fits your philosophy).
Keep the existing pixelShaderPath setting, which could be included in "defaults", and overridden in a particular profile.
The final touch would be to have a list populated with the available shader names, and then have a mechanism and UI similar to the "next tab" mechanism, where you could scroll through the different shaders.
I would love to be able to auto-populate the list of available shaders, but that might not be possible - they could really be anywhere in the OS.
That being said, I also love the idea of previewing the shaders. It would fit in nice with #9818. You'd probably have to manually specify a list of toggleShaderEffects
commands with each of the possible shaders, but then we could definitely live preview them. You'd basically get , but with shaders.
We'd definitely need to work out the edge cases here.
toggleShaderEffects(path=null)
would probably still need to act the same as it currently does - toggle on and off.toggleShaderEffects(path="")
would... always disable? We actually don't have a good way of differentiating between null
and ""
, so that might need to behave like the previous entry.toggleShaderEffects(path="foo.hlsl")
If foo.hlsl
is the current shader path, and shader effects are enabled, disable the shader effects. Otherwise, set the shader path to foo.hlsl
and enable the effects.okay that was easier than I expected
What about a "pixelShaders" section similar to the "schemes" section
"pixelShaders": [ { "pixelShaderPath": "path.to.pixel.shader1.hlsl", "name": "Crt" }, { "pixelShaderPath": "path.to.pixel.shader2.hlsl", "name": "invert" } ]
This would make the list available and elsewhere the shaders could just be referred to by name.
@zadjii-msft So when are we getting a Select Shader...
entry in the command palette? That'd be really cool and make shaders a lot more accessible.
When someone contributes the code 😜 As it currently stands, this probably isn't something that the core team will have dedicated time to get around to. But I'd be more than happy to help guide someone who wanted to contribute this on their own.
I see. So it's not a priority for the core team? That's a bit sad, it could add a lot of fun to Windows Terminal.
Alas, no. We've got to make pretty hard cuts on what we can actually prioritize. I sure agree, shaders are the kind of thing that sparks joy. But we've only got so many dev hours a week to go around. We tend to prioritize requests vaguely around 👍's. So go ahead and hit that like and subscribe to help prioritize this 😉
Add an "enablePixelShader" setting, which can be set to true or false.
If set to "false", but a valid pixelShaderPath was specified, this would enable Windows Terminal to be started without the pixel shader visible, but available at the press of a key combination.