Add Option to always hide Menu Icons

[Rkoturdo-Ndo]

I use the GW2 UI custimizations to hide the top right icons all the time since I do not use them for menus. While using blishHUD there are now some icons that are shown while out of combat. This does look out of place.

If that feature were to be added there should probably be a warning dialogue that reminds the user of how to open the blishUI via shortcut.

It is a small thing, but considering that the option to hide them already exists it might not be to challenging to implement.

[entrhopi]

Theoretically there is a dynamic HUD option to hide them completely, but back in the day when we implemented it for the corner icons we decided that it would be too 'dangerous' to hide them completely (only 'hide during combat' is allowed).

If we were to implement this function, I would recommend the following:

• a warning popup
• check if a hotkey for Blish HUD is defined
• add an option to re-enable the corner icons in the tray context menu

This might not affect custom implementations by module authors and some modules might become inaccessible altogether.
🤔

[dlamkins]

I agree. It should ideally be difficult to accidentally enable this as it would be quite difficult to get out of unless you already know and for users that we assist troubleshooting the issue, it's likely to get treated as one of the other issues (for example, not visible while in DX9 Fullscreen). I think the number of people this helps will be far less than the number of people this may cause problems for.

I do like the idea of the warning (though then the question becomes will they read it? 😁). The tray are icon is a good idea, but isn't super discoverable when you mistakenly enable it. 🤔

[Rkoturdo-Ndo]

All valid problems. A good way to ensure that it can't be accidentally activated is to only make it possible to activate it by manually changing the settins.json .
For example right now the following options already exist:

{
                            "T": "System.Boolean, mscorlib",
                            "Key": "HideOnMissingMumbleTicks",
                            "Value": true
                          },
                          {
                            "T": "System.Boolean, mscorlib",
                            "Key": "HideInCombat",
                            "Value": true
                          },
                          {
                            "T": "System.Boolean, mscorlib",
                            "Key": "HideInWvW",
                            "Value": true
                          },
                          {
                            "T": "System.Boolean, mscorlib",
                            "Key": "HideInPvP",
                            "Value": true
                          },                          

Maybe adding a "HideAlways" that is false by default and can not be changed via the UI would be a great Idea.
This way the only way to do it is by checking the documentation (which could have a huge red warning about possible issues).

This would also decrease the maintenance burden, as no major UI changes would have to be made, the codepath should be pretty short. Though I have not looked into the code yet, so that is an uneducated assumption.

[entrhopi]

This is not entirely correct.

Blish HUD dynamic HUD features relies on DynamicHUDMethod ( https://github.com/blish-hud/Blish-HUD/blob/dev/Blish%20HUD/GameServices/Overlay/DynamicHUDMethod.cs ) which has the exact same options the game uses for its dynamic HUD options. (unless someone messed with this during my absence 😆 )

We decided to disable some of those options depending on the context to avoid user error where the only option would be to open/delete the config file.

We could however consider to just hide those in the UI, as you suggested, so that you can mess with it in the configuration file, if you really want to. 🤔

[Rkoturdo-Ndo]

Thanks for clearing that up for me . Personally it would make blishHUD way better for me (I have a thing for little things bothering me way more than they should ^^), but in the end it would be up to you devs to decide :D

Usererror could be an issue so if I would definietly only suggest it to be an option by editing the config directly.

[dlamkins]

I agree that having to manually edit the settings file seems like a reasonable compromise. It's not going to accidentally happen and is similar to what we do with some other settings (for example, custom module repos, and pathing's advanced options in its yaml).

[entrhopi]

Ok!
I'll put that on my todo for tomorrow.