Is there a way to get the Gateway to remember that I want to display the Description column all the time? It's really annoying to have to re-check that box every time I access the Gateway.
No. There is no concept of "Browser Session Preferences" in the Gateway. When the DESCRIPTION column is not shown, descriptions should be available as tooltips next to the name of each project, so that data is being made available even without the column being displayed. If your goal is very specifically to always have the column displayed, I'm afraid it is unlikely to ever happen at the session level. There's the potential we could flip a code setting on the application side, but that would then apply to all gateways using that later version; it seems pretty undesirable to force that behavior on everyone.
Each system was left to their own devices to determine which columns are displayed on their pages. As a consequence, you'll see some pages which have a DESCRIPTION column displayed by default (like User Sources), and some which don't. I believe the rough decision was based on the count of columns, but I can't speak for whether each team held to that guidance. The reasoning being that many columns displayed at once results in each column receiving (linearly and relatively) less width, resulting in description columns displaying like the attached photo. That behavior was deemed undesirable (rightly so, in my opinion), and so pages with many columns hide DESCRIPTION by default.
There's an argument for a gateway-wide setting, but some resources are far more likely to have descriptions than others, and forcing all-on or all-off likewise seems heavy-handed.
What's the use-case which requires regular access to the Description information?
Makes sense. For me specifically, I have multiple copies of projects where I store versioning information in the description and I need to refer to it and change it when pushing out a revision. It's nothing critical, just something I was used to doing in 8.1.
It seems odd that you are able to de-select Name. It almost implies that some users might have unintelligible project Names and have human readable project Descriptions. Not sure if that is the case for anyone, but given how the Name has implications for operation and shouldn't be changed, I could see use cases where Description might hold critical info/notes for other developers across a couple copies of the same/similar project.
This is a really bad practice, as it will bite you in the [expletive] if you have gateway events defined.
The projects don't have the same name, so that shouldn't matter? I do recognize it is bad practice, if just from the standpoint that I have to manually change the value, but, as far as I'm aware, there is no other versioning method within Ignition? I would love to be wrong about this btw.
Also, I work for a system integrator, so we have a lot of projects from our customers. Often we will keep the backups in a git repo, but the one we pull into our company's gateway would be whatever the latest from the customer's gateway is. So we add a version comment to the description so we know which one it is. The customer may have no revisioning methodology, so we have to work with whatever they give us.
If you copy a project to a new name for versioning purposes, any gateway events defined within will fire in both projects. You have to be extraordinarily disciplined to always disable such after copying, or not ever using gateway events. Needing the description field for inter-developer notes implies insufficient discipline.
That implies you aren't replicating your client's environment to the gateway level, down to the gateway version. (Each client gateway should be spun up in a matching VM, or pulled into your dev gateway as a whole.)