FR: Add Key class to the library

[camdroid]

Playing around with this, I wanted to treat keys as individual objects rather than needing to put the code for all the different keys into one function based on style/callback (use key.get_style() rather than get_key_style()). I tried playing around with the project examples in my repo, and got to a point where I'm fairly happy with it (at least Key and its subclasses, the rest of my code is still a mess). Specifically in basic.py, key.py, emoji_key.py, and exit_key.py.

It seems to make sense to me that Key would be its own class related to the deck, and users would be able to assign functionality/styles by key class rather than all in one callback function, but I'm not terribly familiar with this project yet. Is there any reason not to do it that way, or reasons that that would be a terrifically difficult change?

[abcminiuser]

Thanks for the interest @camdroid!

I have thought about this sort of thing in the past -- in fact, I do something similar in my related project (see https://github.com/abcminiuser/python-homeassistant-streamdeck/tree/master/src) that uses this one and encapsulates the keys (tiles) into subclasses with attributes.

Ultimately I've tried to keep this library core as simple as possible, as it's unlikely that anything I come up with will fit the exact use-case of other projects. That's the core reason I went with a "single callbacks with key index, along with functions accepting key indexes" for the library, as it means that people can easily couple it to their own projects in a manner that suits them best.

That said, it's open for discussion, as the whole point of this project was to make something that's useful to others. If enough people think there's merit to this idea, I'm not against modifying the library API.

[camdroid]

That's totally fair! Just to lay out my thoughts, I do think that adding a Key/Tile class to the library makes it simpler to work with - I think if people want to create a new button, they'll only want to deal with 1) what they want the button to look like, and 2) what they want the button to do. Adding this as a class makes the overall code more modular (more extensible), and puts both requirements into one file, without needing to modify other files in the core library. And then new devs have a clear direction for how to build a button (create a file, override these two functions, rather than needing to figure out how the callback interacts with all the other buttons.

Also, I did really like the "More Actions" section of the default StreamDeck app - this is probably totally pie-in-the-sky thinking, but it'd be cool to see something like this project with a UI that allows people to customize the functionality of their device in a similar manner to the desktop app, and allows people to add custom buttons to a "store" where other users can install them without needing to know how to code. I'm not sure how that would work with a unified callback function (but I haven't given it a ton of thought, and don't know whether that's even a direction you'd be interested in).

Ultimately, this is your project, so if you think adding it as a separate class would make it more complicated and less likely to meet other use cases, I totally respect that. The code you've written here has already been super useful for me (I've never worked with HID stuff before), and I'm plenty happy with building my custom use case on my own. :)

[camdroid]

Oops, accidentally hit close, but happy to leave this open in case you had more thoughts. 😬 If that's everything, feel free to re-close it!

[abcminiuser]

If you're looking for a custom StreamDeck UI that allows you to customize the button functions, someone recently released their own open source project that uses this library to achieve that.

I'll have to have a think about this some more; now that I'm learning more about Python and particularly Pythonic idioms there's a few API changes I'd like to make before 1.0, but they're definitely going to have to wait until I've found a stable HID back-end that works across all three major platforms.

[camdroid]

That's awesome, I'll take a look at that one, too! I'm fairly familiar with Python, so happy to chat over what would make for a Pythonic solution or not for different aspects of the code (I'm no expert, just worked with it for a couple years).