Wish: reverse order of page numbers about companion HOT 5 CLOSED

On Mon, 28 May 2018 at 11:36, dnmeid ***@***.***> wrote: I've done a survey in a group with 700 AV people. I asked should the pages be incremented with arrow up or arrow down. After 24h 20 perfer page increment to be arrow up and 11 prefer it to be arrow down. The up supporters are almost all lighting guys, the down supporters are almost all sound and video guys. (The group has more lighting guys than sound and video) Some suggested the most natural and intuitive way would be left/right buttons with right is increment. One audio guy mentioned that on many audio consoles the direction is user definable. After rethinking all of that I think we should drop the concept of the pages like they are at the moment and replace it with a more flexible solution. Also thinking of upcoming multi-device functionality. My proposal: Introduction of windows or whatever you want to call it. Basically a window should be a 2d array of buttons mapped onto physical keys. Like in a computer window, when the key area is smaller than the button array, overflow with scrolling can happen. Properties of a window are id or name, position on keys (top left), border size (w,h), pane size (w,h), pane position (x,y). We should introduce companion as a new pseudo-device and offer actions to control it: window open at position (x/y and size w/h) (also brings window on top), window close, window scroll (direction and increment), window scroll to (x/y). One can rebuild the workflow like it is with two windows. Window one occupying the three left buttons and window two occupying the remaining buttons. In window one you have buttons for scrolling window two up or down (or left and right). The big advantage is, that you can have much more flexibility. Lets say I have only two pages. I can make one window with a button in top left "scroll to where page two is" and on page two in the same location one button with "scroll to where page one is". This also is a solution for the sticky button request. Just make a second window and don't scroll it. If you only wan't to have one sticky button and it should be in the middle of the keys, no problem, just make sure window two is on top of window one. That means windows should not be brought to front when using a button. Also the Page navigation system suggested by Deanbau could be user programmable that way, you just have to open a window with several buttons to new windows with several buttons to scroll positions. Ok it will take some time to program this as a user, but the point is that the power and flexibility is at the user end and they can customize their control surface the way they want. Button naming could be w.y.x (w= window no, y= row no, x=column no). My suggestion is that the pane size is virtually infinite (fixed to some technical limit), so you can just place your buttons anywhere you want an scroll there, you don't have to grow the pane when you need more space and, more important, we don't need to reflow buttons when the pane shrinks. Of course we need parameters for actions for that, but we need parameters anyway. One more addition to the button flexibility (maybe I should do new issue): We should have a button pool. That means when creating a button with actions and so on it gets created in a pool and you can use the pool objects and place them in windows. With that you can reuse the button/have more instances of the same button. When editing the button you edit the pool object and all other instances reflect the edit. Copying a button in a window creates a new instance, copying in the pool creates an independent new button. We can also enumerate the pool objects and maybe put that number in the top right of a button. BTW: Button creation and assignment should be drag and drop. Discussion is open! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaBkpYGGzY95HFjkfyU4nlKKCPnllxRks5t28T_gaJpZM4UPEwx> .