Skip to content
This repository has been archived by the owner on Apr 22, 2021. It is now read-only.

GUI Improvements #1648

Open
9 of 33 tasks
5HT2 opened this issue Nov 29, 2020 · 6 comments
Open
9 of 33 tasks

GUI Improvements #1648

5HT2 opened this issue Nov 29, 2020 · 6 comments

Comments

@5HT2
Copy link
Member

5HT2 commented Nov 29, 2020

For after #1510 is merged.

  • HUD Grid to make aligning hud components much easier.
    • Maybe with customizable size (eg 5px)
    • Preview
    • When holding alt
  • Auto docking
  • Themes (Formerly Custom GUI colors #32)
  • "Categories" for different things
    • Switching via icons at the top
    • HUD
    • Client related settings
      • Button to set all module visibility to false
    • Friends manager
    • Alt manager
    • Macro / script (Scripting API #1367) editor
  • Option to display modified settings in a bold font
  • Descriptions for settings
  • Frequently used / Favorites
  • Target Hud (Targethud #1529)
  • Customizable Item Count
  • Radar
    • Player / hostile / passive / neutral options
    • Newchunks option
  • Potion UI
  • User custom module categories
  • Make window corner roundness customizable
  • Readd old module list options
    • > Arrow option
    • Custom color gradient (up to 5 colors)
    • Category color options
    • Custom rainbow options such as saturation
    • Custom single color
    • Cycling saturation option for a single color
  • Legacy text radar
@5HT2 5HT2 added -module enhancement -blocked Something is preventing this from being possible -gui and removed -module labels Nov 29, 2020
@5HT2 5HT2 added this to the long-term milestone Nov 29, 2020
@5HT2 5HT2 removed the -blocked Something is preventing this from being possible label Jan 4, 2021
5HT2 added a commit that referenced this issue Jan 5, 2021
@omninope
Copy link
Contributor

omninope commented Jan 6, 2021

Suggestions:

  • Ability to keybind Hud elements. Useful because some things like CombatItemCount, CrystalDamage and Targethud (when it gets implemented) are only used in combat an a bind is easier and faster than making another profile and loading it, especially when the player needs to engage in combat immediately. Done in commit d0a78db
  • Ability to input negative ammounts. Useful for things like ItemModel.
  • Maybe less useful: Ability to scale InventoryViewer separately, because people with lower resolution monitors may want their GUI small but still want to clearly see what is in their inventory. Done in commit f49ca78.

@5HT2
Copy link
Member Author

5HT2 commented Jan 6, 2021

Ability to input negative ammounts. Useful for things like ItemModel.

This isn't a GUI thing as much as it is a setting thing. None of the settings allow negative values, though they could.

I think a power user solution would be to allow the user to set any value with the ;set command, ignoring the gui limits. If someone is using commands and they mess up, it's their fault.

Future does the same thing as well. I think it's the easiest way to idiot proof the GUI while allowing power users to set whatever they want

@Luna5ama Luna5ama pinned this issue Jan 7, 2021
@5HT2 5HT2 mentioned this issue Jan 12, 2021
20 tasks
@Luna5ama
Copy link
Contributor

Ability to input negative ammounts. Useful for things like ItemModel.

This isn't a GUI thing as much as it is a setting thing. None of the settings allow negative values, though they could.

I think a power user solution would be to allow the user to set any value with the ;set command, ignoring the gui limits. If someone is using commands and they mess up, it's their fault.

Future does the same thing as well. I think it's the easiest way to idiot proof the GUI while allowing power users to set whatever they want

No. It always allow negative number if the range allows.
And no, it would causes weird bugs to make it ignores limit and handling it in code side would create tons of bloat plate code.

@5HT2
Copy link
Member Author

5HT2 commented Jan 12, 2021

And no, it would causes weird bugs to make it ignores limit and handling it in code side would create tons of bloat plate code.

That's fine imo. If the user uses a set command or something to set a value out of range that's their fault.

@Luna5ama
Copy link
Contributor

And no, it would causes weird bugs to make it ignores limit and handling it in code side would create tons of bloat plate code.

That's fine imo. If the user uses a set command or something to set a value out of range that's their fault.

It isn't. If it causes crash then resetting the value will be pain. You have to go into the config and search then edit it manually. 🗿

@5HT2
Copy link
Member Author

5HT2 commented Jan 12, 2021

Okay I guess

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants