search

SGA-A / c2c

Source code for the custom app exclusive to cc
MIT License
1 stars 0 forks source link

Rewrite tempvoice for better UX #135

Closed SGA-A closed 2 months ago

SGA-A commented 3 months ago

Is your feature request related to a problem? Please describe.

It is kind of frustrating having to type out a command to rename your voice channel or change the bitrate of it, and frankly there are much better ways of going around this. Examples are buttons and selects. I'd like to make it so that you only have to type out one command to manage everything all at once. Voice info, voice privacy settings, voice editing should all be possible within a single command which holds a view to make it possible.

Describe the solution you'd like

The /setup command would still exist, but we'd remove all of the voice subcommands for a single one named /voice manage where you can interface with everything there is to know about your voice channel and what changes can be made. Similar to other bots, it'd be nice if an image of icons and they're respective meaning is displayed, but it doesn't have to be. There can be labels on the buttons, but regardless there must also be some emoji to represent the action that can/would be taken when the button is clicked.

Here's an outline of each of the buttons I have in mind so far, all applicable only to the user's own voice channel:

We also want to change the internals of how changes are comitted into the database. When you join a voice channel, a new object instance could be created which holds metadata on that channel and this is stored in a list of active temporary voice channels (like a dataclass or attrs). It's created upon acquiring the metadata from the db, and the db never interacts with the user again until all members of the voice channel have left.

Meaning that when a user makes a change, it should be identifiable and hence know when to make a commit. For example, the dataclass could hold all the attributes associated with a modifiable tempoary voice channel (name, bitrate, etc) and also an attribute that tracks whether or not changes were made when the instance of the object was created by joining the creator channel and moving into a new temporary voice channel. J. Murphy's video on dataclasses might help.

When the user leaves the voice channel, we would need to detect via the changes_made attribute (just made this up), as to whether or not we should commit any changes to the database and possibly another attribute that provides the list of names of what attributes actually got changed so that we don't need update the entirety of the columns associated with the row. But that is not a requirement.

Describe alternatives you've considered

We may still consider leaving support for the voice subcommands, as they are often faster. I did mention that there will be a single command to manage your channel, but if we approve leaving support for the legacy voice subcommands (which will still need to be rewritten and decomposed into functions so that it can be reused by the main management view), it may become a persistent view instead which is reused and created when the /setup command is called in a respective guild (similar to how other bots work).

Additional context

None

SGA-A commented 3 months ago

Dataclass docs https://docs.python.org/3/library/dataclasses.html In particular, look into the field param and how they work. How to set, store and retrieve these object instances.

SGA-A commented 2 months ago

In the end, we've decided to drop this functionality completely. Voice channels weren't meant to be created and deleted constantly, and you can see this by looking at the create channel endpoint bucket ratelimits. This functionality also received little to no usage so it felt trivial to continue development on it.