-
-
Notifications
You must be signed in to change notification settings - Fork 512
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
feat: support grid size in protocols #2639
Conversation
Rosstalk syntax requires the page:bank structure. so how should this be done? This reverts commit 576fbe9.
I think with the current handling of colors it is possible to allow any CSS color string (except color names, it is possible to use color names for setting colors, but the color picker in the ui doesn't know how to show them). |
@dnmeid good point. I've made sure that the one protocol which exposes that info (emberplus) will handle it, but I have left everything setting the value as a number as that is what it was doing before. |
# Conflicts: # lib/Service/Api.js # lib/Service/EmberPlus.js
Hey @Julusian , not sure if this is the best place to ask this, but I was wondering if there's a reason that the new button names need to begin at 0/0? If they began at 1/1 then it would be faster to identify the total grid size (ie 4/8) when dealing with larger grids, rather than having to -1 from each row and column. |
It is because they can go negative too. The idea being that you can grow the grid in every direction, and have a central 'home position' rather than only being able to grow to downwards and to the right. |
Ok thanks! |
To that end, is it possible for me to custom build a grid where the home position is 1/1? |
Replaces #2616
Fixes #2299
Extend the TCP, UDP, OSC, Emberplus and HTTP protocols to support the new button location syntax, and improves the consistency of what is available in each API.
Additionally, this reworks the protocols to be structured in a more RESTful structure, tackling part of #2079
Also includes unit tests for the new sections. The old sections are marked as deprecated and have been moved to behind config fields to discourage their use.
Perhaps in a few releases time companion should forcefully disable the legacy protocols (and remove documentation) as a reminder of them being removed soon, and a couple of releases after that remove those portions entirely?
Keeping them around doesn't have much cost, but it does add noise to the docs and code