Add support for keyboards and buttons

[emilyalbini]

Keyboards and inline keyboards are a great way for users to interact with your bot: they allows you to create rich user interfaces, integrated in the Telegram client.

In botogram, keyboards and buttons (I prefer this name than "inline keyboards") will be implemented simoultaneously, sharing most of their code. This creates a coerent API, and allows you to switch between keyboards and buttons really easily.

Both keyboards are buttons are built around the concept of callbacks: when someone clicks a key/button, a specific function you define will be called. Buttons natively supports this feature, while for keyboards this will be implemented by botogram.

@bot.callback("color_chosen")
def color_chosen_callback(chat, user, callback, args):
    chat.send("%s chosen %s!" % (user.name, args[0]))

@bot.callback("exit")
def exit_callback(chat, user, callback):
    callback.notify("Bye, I will miss you :(", alert=True)

@bot.command("ask")
def ask_command(chat, message, args):
    btns = botogram.buttons()
    btns[0].callback("Red", "color_chosen", ["red"])
    btns[0].callback("Blue", "color_chosen", ["blue"])
    btns[1].callback("Exit", "exit")

    chat.send("Which color do you prefer?", attach=btns)

The code above will create a /ask command, which sends the "Which color do you prefer" message to the chat. Below that message, there will be two rows of buttons: the first row with "Red" and "Blue", and the second row with "Exit". Clicking on one of the color will invoke color_chosen_callback with the color as an argument, while clicking on the exit button will display an alert.

The API for keyboards will be almost the same (callbacks mocked in by botogram, other features such as callback.notify unavailable).

[emilyalbini]

This issue replaces issue #6.

[NicolaiSchmid]

Is there anything new about this topic? I would be happy to contribute code

[emilyalbini]

@f7f7u7f7 I'm not working on this now, feel free to send a pull request, and to contact me if you have any question or trouble during the implementation.

My plan of action was to first implement support for inline keyboards (I personally prefer to call them buttons), and then build support for keyboards on top of it, mocking callbacks support on top of it (if the received message is the same as the button, invoke the callback).

This way the API is similar between the two implementaions, allowing to reuse parts of the inline one for the standard keyboards, and the inline keyboards are more similar to the API I envisioned. Also, if it's not a problem for you multiple pull requests for the different parts of the implementation would be best for code review :)