Microsoft appears to be blocking even more apps for customizing the user interface in Windows 11 24H2. Users noticed that ExplorerPatcher joined the recently blocked StartAllBack app.
TLDR: StartAllBack, ExplorerPatcher and some other projects are being blocked on 24H2.
I put in the effort to redesign my work flow from VS (Enterprise license) to VS Code (totally free) earlier this year. I thought it couldn’t be done, but it was easier than I thought. I’m super happy with the result as I hated what they did with recent VS versions. Microsoft just can’t stop fucking up perfectly fine UIs in the name of “progress”.
The biggest thing is the UI being completely different. I did use VS Code before, but only for my own projects, not stuff for work. So I did know how to use VS Code, but still it’s a major mental adjustment with everything being in a different place, features and shortcuts working differently etc.
I really missed to Solution Explorer, which is probably my most used tool during work. But thankfully there is an excellent plugin which provides a Solution Explorer in VS Code. It’s a bit different from what I’m used to but it works just fine.
Normally for casual profiling I’d use VS builtin tools. Only switching to something like DotMemory when really diving into optimization. This seems to be missing from VS Code. Probably there’s a plugin to fix that, but I want to keep the number of plugins to a minimum to prevent issues of plugins not being updated or having compatibility issues as much as possible. So now I switched to a different work flow for this to use tools like DotMemory sooner instead of the builtin stuff from VS.
Resharper isn’t available for VS Code yet, but I don’t mind it. Some of my colleagues use it, but I prefer to do everything myself anyways and not use automated tools for code.
I miss the Nuget package manager. Everything can be done using the terminal, both in VS and VS Code, which works the same. But the UI provided by the manager is so nice, it shows all the info you need, let’s you do almost anything with two clicks. I’ve checked out some plugins which are supposed to help with this, but have found none as good as the VS package manager. I’m proficient enough with the terminal it doesn’t really matter, but I still miss the manager and find myself checking different sources manually which used to be a lot more efficient. So I’ve taken an efficiency hit here, but I still can get the job done.
Having everything done in the terminal panel takes some getting used to, where VS often launches different windows to get different kind of outputs. This is just something to get used to and could probably be changed in the settings, but I think it’s fine.
In VS the project is launched as a separate process and then VS attaches itself to the process for debug and inspection purposes. In VS Code it’s a subprocess of the main editor process. This has some implications using third party tools for profiling for example. But I haven’t noticed anything going wrong. I think the way VS does it is better, but it’s probably fine? In theory an application could crash the whole VS Code process. But my code never crashes so I should be fine, right?
Running and debugging is different but fine, with different profiles and debugging flags being managed from the UI and working perfectly. Publishing however is done only using the terminal, not the UI. Everything I need is available, but it took some figuring out how I need to do stuff using the terminal with regards to publishing. I’ve created a page on Confluence for myself with all the different stuff, which flags etc. It took some time but I think I’ve got everything figured out.
For version management we already used a third party tool, so luckily no changes there. I have had to set some new ignores, but other than that no changes.
Creating new projects is something I haven’t figured out how to do. For work I only ever work in existing projects that have been around for ages. I don’t know how easy it would be to create something new with all the required files and parameters so my colleagues can also use it. The other day I wanted to quickly check something in an empty project and I had to reach for VS again (for shame). I need to put in some time figuring this out in VS. It’s probably not complicated, but as I said I wanted to check something quickly so I didn’t have the time.
There are probably a thousand little things I have changed or have to get used to. But these are the main ones.
As someone who genuinely loves the command line - I’d like to know more about your perspective. (Genuinely. I solemnly swear not to try to convince you of my perspective.)
What about GUIs appeals to you over a command line?
I like the CLI because it feels like a conversation with the computer. I explain what I want, combining commands as necessary, and the machine responds.
With GUIs I feel like I’m always relearning tools. Even something as straightforward as ‘find and replace’ has different keyboard shortcuts in most of the text-editing apps I use - and regex support is spotty.
Not to say that I think the terminal is best for all things. I do use an IDE and windowing environments. Just that - when there are CLI tools I tend to prefer them over an equivalent GUI tool.
Anyway, I’m interested to hear your perspective- what about GUIs works better for you? What about the CLI is failing you?
Not OP. Used Linux since the late 90s. My daily driver is NixOS. GUI here is synonymous with TUI.
What about GUIs appeals to you over a command line?
I like the GUI because I can see what options the tool can execute in this state. I don’t have to pass --help to grep or keep several man page sections open. The machine knows what it’s capable of and I direct it.
With CLIs I feel like I’m always relearning tools. Even something as straightforward as ‘enable a flag’ has different syntax. Is it -flag? --flag? --enable-flag? Oh look, a checkbox.
Not to say that I think a window environment is best for all things. When using an IDE, I have the terminal open constantly. Programmers are as bad at visual interfaces as they are module interfaces. If no UX designer was involved in displaying complex data or situations, I’m likely to try to fall back to the commandline. Just that - when there are GUI tools I tend to prefer them over an equivalent CLI tool.
tl;dr GUIs can represent the current state of a complex process and provide relevant context, instead of requiring the user to model that information (with large error bars for quality of the UI).
Anyway, I hope you take this in good humor and at least consider a TUI for your next project.
I hope you take this in good humor and at least consider a TUI for your next project.
Absolutely. I see what you did there… 😉
But seriously, thank you for your response!
I think your comment about GUIs being better at displaying the current state and context was very insightful. Most CLI work I do is generally about composing a pipeline and shoving some sort of data through it. As a class of work, that’s a common task, but certainly not the only thing I do with my PC.
Multistage operations like, say, Bluetooth pairing I definitely prefer to use the GUI for. I think it is partially because of the state tracking inherent in the process.
Thanks for your reasonable reply and question! As for what I love about UI, it’s simple;
I don’t have to remember what to enter, just the pathway to get there.
With command line, you have to remember commands, arguments, syntax, and gods forbid you enter something wrong. It won’t work.
But with a (decently designed) UI, you merely have to remember the path you took to get to wherever you want to go, what buttons to press, what mouse movements to execute.
As someone with a limited attention span and energy to do things, this is a lifesaver.
As for Visual Studio, that’s a development preference. Code is too different for me to be comfortable in it, and relies on command line too much.
with a (decently designed) UI, you merely have to remember the path you took to get to wherever you want to go, what buttons to press, what mouse movements to execute.
I think that’s very insightful. I certainly have developed muscle-memory for many of my most-frequent commands in the CLI or editor of choice.
I agree about Visual Studio as a preference. I’ve used (or at least tried) dozens of IDE setups down the years from vi/emacs to JetBrains/VS to more esoteric things like Code Bubbles. I’ve found my personal happy place but I’d never tell someone else their way of working was wrong.
(Except for emacs devs. (Excepting again evil-mode emacs devs - who are merely confused and are approaching the light.)) ;)
I’ll switch to Linux when Visual Studio Community (NOT Code) works on it and I never have to touch the command line ever again.
Just switch to code.
I put in the effort to redesign my work flow from VS (Enterprise license) to VS Code (totally free) earlier this year. I thought it couldn’t be done, but it was easier than I thought. I’m super happy with the result as I hated what they did with recent VS versions. Microsoft just can’t stop fucking up perfectly fine UIs in the name of “progress”.
Got any highlights of things you had to adjust to?
The biggest thing is the UI being completely different. I did use VS Code before, but only for my own projects, not stuff for work. So I did know how to use VS Code, but still it’s a major mental adjustment with everything being in a different place, features and shortcuts working differently etc.
I really missed to Solution Explorer, which is probably my most used tool during work. But thankfully there is an excellent plugin which provides a Solution Explorer in VS Code. It’s a bit different from what I’m used to but it works just fine.
Normally for casual profiling I’d use VS builtin tools. Only switching to something like DotMemory when really diving into optimization. This seems to be missing from VS Code. Probably there’s a plugin to fix that, but I want to keep the number of plugins to a minimum to prevent issues of plugins not being updated or having compatibility issues as much as possible. So now I switched to a different work flow for this to use tools like DotMemory sooner instead of the builtin stuff from VS.
Resharper isn’t available for VS Code yet, but I don’t mind it. Some of my colleagues use it, but I prefer to do everything myself anyways and not use automated tools for code.
I miss the Nuget package manager. Everything can be done using the terminal, both in VS and VS Code, which works the same. But the UI provided by the manager is so nice, it shows all the info you need, let’s you do almost anything with two clicks. I’ve checked out some plugins which are supposed to help with this, but have found none as good as the VS package manager. I’m proficient enough with the terminal it doesn’t really matter, but I still miss the manager and find myself checking different sources manually which used to be a lot more efficient. So I’ve taken an efficiency hit here, but I still can get the job done.
Having everything done in the terminal panel takes some getting used to, where VS often launches different windows to get different kind of outputs. This is just something to get used to and could probably be changed in the settings, but I think it’s fine.
In VS the project is launched as a separate process and then VS attaches itself to the process for debug and inspection purposes. In VS Code it’s a subprocess of the main editor process. This has some implications using third party tools for profiling for example. But I haven’t noticed anything going wrong. I think the way VS does it is better, but it’s probably fine? In theory an application could crash the whole VS Code process. But my code never crashes so I should be fine, right?
Running and debugging is different but fine, with different profiles and debugging flags being managed from the UI and working perfectly. Publishing however is done only using the terminal, not the UI. Everything I need is available, but it took some figuring out how I need to do stuff using the terminal with regards to publishing. I’ve created a page on Confluence for myself with all the different stuff, which flags etc. It took some time but I think I’ve got everything figured out.
For version management we already used a third party tool, so luckily no changes there. I have had to set some new ignores, but other than that no changes.
Creating new projects is something I haven’t figured out how to do. For work I only ever work in existing projects that have been around for ages. I don’t know how easy it would be to create something new with all the required files and parameters so my colleagues can also use it. The other day I wanted to quickly check something in an empty project and I had to reach for VS again (for shame). I need to put in some time figuring this out in VS. It’s probably not complicated, but as I said I wanted to check something quickly so I didn’t have the time.
There are probably a thousand little things I have changed or have to get used to. But these are the main ones.
As someone who genuinely loves the command line - I’d like to know more about your perspective. (Genuinely. I solemnly swear not to try to convince you of my perspective.)
What about GUIs appeals to you over a command line?
I like the CLI because it feels like a conversation with the computer. I explain what I want, combining commands as necessary, and the machine responds.
With GUIs I feel like I’m always relearning tools. Even something as straightforward as ‘find and replace’ has different keyboard shortcuts in most of the text-editing apps I use - and regex support is spotty.
Not to say that I think the terminal is best for all things. I do use an IDE and windowing environments. Just that - when there are CLI tools I tend to prefer them over an equivalent GUI tool.
Anyway, I’m interested to hear your perspective- what about GUIs works better for you? What about the CLI is failing you?
Thank you!
Not OP. Used Linux since the late 90s. My daily driver is NixOS. GUI here is synonymous with TUI.
I like the GUI because I can see what options the tool can execute in this state. I don’t have to pass
--helptogrepor keep several man page sections open. The machine knows what it’s capable of and I direct it.With CLIs I feel like I’m always relearning tools. Even something as straightforward as ‘enable a flag’ has different syntax. Is it
-flag?--flag?--enable-flag? Oh look, a checkbox.Not to say that I think a window environment is best for all things. When using an IDE, I have the terminal open constantly. Programmers are as bad at visual interfaces as they are module interfaces. If no UX designer was involved in displaying complex data or situations, I’m likely to try to fall back to the commandline. Just that - when there are GUI tools I tend to prefer them over an equivalent CLI tool.
tl;dr GUIs can represent the current state of a complex process and provide relevant context, instead of requiring the user to model that information (with large error bars for quality of the UI).
Anyway, I hope you take this in good humor and at least consider a TUI for your next project.
Absolutely. I see what you did there… 😉
But seriously, thank you for your response!
I think your comment about GUIs being better at displaying the current state and context was very insightful. Most CLI work I do is generally about composing a pipeline and shoving some sort of data through it. As a class of work, that’s a common task, but certainly not the only thing I do with my PC.
Multistage operations like, say, Bluetooth pairing I definitely prefer to use the GUI for. I think it is partially because of the state tracking inherent in the process.
Thanks again!
Thanks for your reasonable reply and question! As for what I love about UI, it’s simple;
I don’t have to remember what to enter, just the pathway to get there.
With command line, you have to remember commands, arguments, syntax, and gods forbid you enter something wrong. It won’t work.
But with a (decently designed) UI, you merely have to remember the path you took to get to wherever you want to go, what buttons to press, what mouse movements to execute.
As someone with a limited attention span and energy to do things, this is a lifesaver.
As for Visual Studio, that’s a development preference. Code is too different for me to be comfortable in it, and relies on command line too much.
Thank you for responding! I really liked this bit
I think that’s very insightful. I certainly have developed muscle-memory for many of my most-frequent commands in the CLI or editor of choice.
I agree about Visual Studio as a preference. I’ve used (or at least tried) dozens of IDE setups down the years from vi/emacs to JetBrains/VS to more esoteric things like Code Bubbles. I’ve found my personal happy place but I’d never tell someone else their way of working was wrong.
(Except for emacs devs. (Excepting again evil-mode emacs devs - who are merely confused and are approaching the light.)) ;)