-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allowing user to choose presets. #183
base: main
Are you sure you want to change the base?
Conversation
Hi @ShaomingT, thanks this looks great! I was wondering if there's a nicer way UX-wise to let the user select a preset from the list? Maybe using inline buttons? |
Hi @n3d1117 ! Thanks for the idea! A potential issue is that if the user sets many modes (e.g. nine modes), it could be hard to use with inline buttons. Please let me know your thoughts on this. I'm happy to discuss this! |
Sure, is there a limit on the number of inline buttons that can be shown? |
It looks like the doc didn't mention the limit number of inline buttons. If there are many rows and columns showing buttons, and considering the length of the text on the buttons, it can make the interface more difficult to recognize. One solution is to only display the first few modes (e.g. 4 modes) as inline buttons. If there are more options, the |
Hey, how about a scrollable list of buttons, if there are too many. Navigating with a import math
from telegram import InlineKeyboardButton, InlineKeyboardMarkup
from telegram.ext import CommandHandler, CallbackQueryHandler
# Your list of items
items = ['Item 1', 'Item 2', 'Item 3', 'Item 4', 'Item 5', 'Item 6', 'Item 7', 'Item 8', 'Item 9', 'Item 10']
ITEMS_PER_PAGE = 5
def build_keyboard(page):
n_pages = math.ceil(len(items) / ITEMS_PER_PAGE)
start = page * ITEMS_PER_PAGE
end = start + ITEMS_PER_PAGE
keyboard = []
for i, item in enumerate(items[start:end], start=start):
keyboard.append([InlineKeyboardButton(f"{i+1}. {item}", callback_data=f"item-{i}")])
# Navigation buttons
navigation_buttons = []
if page > 0:
navigation_buttons.append(InlineKeyboardButton("Previous", callback_data=f"previous-{page}"))
if page < n_pages - 1:
navigation_buttons.append(InlineKeyboardButton("Next", callback_data=f"next-{page}"))
keyboard.append(navigation_buttons)
return InlineKeyboardMarkup(keyboard)
def list_items(update, context):
message = "Choose an item:"
keyboard = build_keyboard(0)
update.message.reply_text(message, reply_markup=keyboard)
def handle_button_click(update, context):
query = update.callback_query
data = query.data.split('-')
action = data[0]
index = int(data[1])
if action == "item":
query.answer(f"You selected item {index+1}: {items[index]}")
else:
if action == "next":
new_page = index + 1
elif action == "previous":
new_page = index - 1
keyboard = build_keyboard(new_page)
query.edit_message_reply_markup(reply_markup=keyboard)
def main():
updater = Updater(TOKEN, use_context=True)
dp = updater.dispatcher
dp.add_handler(CommandHandler("list_items", list_items))
dp.add_handler(CallbackQueryHandler(handle_button_click))
updater.start_polling()
updater.idle()
if __name__ == '__main__':
main()
|
I think we should have two methods for different use cases:
The first one is for people who have lots of modes and know what they want. It's more like a programmer's way. The second one is more general and user-friendly if they have fewer modes. I think scrolling through a bunch of pages to find the one that the user wants may not be a good user experience. |
Alright, fair enough, it's personal preference and your suggestion is a good compromise. The button part could be added in a later update. An alternative would be not having the mode persist between resets. Then you could add the first method you proposed to the
|
@AlexHTW
You can compare the temperature between 0.1 and 1.9. The result will be obvious. The logic is:
I'll investigate the bug "not remember config per user" Thanks for your suggestion; now I understand the goal of the project. Consider the following solution ->
Case 2
|
Hey @ShaomingT,
That's great, some of them would be really nice to customize through a command per server. Some would be really great per user, such as model, image_size and of course mode. What do you think about extending the usage_tracker class (and the usage_logs json files) with a That way it will also persist between server restarts. {
"user_name": "@user_name",
"current_cost": {
"day": 0.45,
"month": 3.23,
"last_update": "2023-03-14"
},
"usage_history": {
"chat_tokens": {
"2023-03-13": 520,
"2023-03-14": 1532
},
"transcription_seconds": {
"2023-03-13": 125,
"2023-03-14": 64
},
"number_images": {
"2023-03-12": [
0,
2,
3
]
}
},
"settings": {
"mode": "code",
"model": "gpt-4",
"image_size": "512x512"
}
}
You are right, it is much cleaner that way. My suggestion was only a temporary solution. |
Changes
/mode [mode_name]
to allow users to switch between presets.These changes will allow users to easily switch between different preset configurations.
Thank you!