I’d like to maintain a consistent ordering of UI controls across patterns (e.g. color picker first, speed slider second, pattern-dependent control third). When in the Edit tab they take the order that they are defined in, which is great, but in the Pattern tab they switch to what appears to be alphabetical grouped by type?
One workaround is to prefix each one with a number (1 Color, 2 Speed, 3 Size, etc.), but this is kind of cluttery.
Any suggestions?
Hey @roden (amazing username - crater reference?) - great observation. Seems like they should keep the order they’re defined in, like on the edit tab. I think I can predict why they work this way now. @wizard - feasible?
Hey @roden - Actually, I wasn’t able to reproduce this behavior. As long as I save any changes from the Edit tab, I’m seeing the order of pattern controls in the pattern list match the order in the Edit tab.
Would you be able to record a short video showing what you’re seeing?
Hi @jeff, thanks for looking into this.
I just updated to the newest version and did some more testing. It now seems to be mostly working. The one issue that I’m now seeing is a toggle switch appearing out of order (first two screenshots, the Edit screenshot is just after saving). Once returning to the Patterns tab I have to switch to another pattern and then switch back before the ordering change happens.
In the third screenshot it is showing an order that is neither alphabetical nor the definition order. This change happened when I updated the Pixelblaze, and once I edited and saved that pattern it went away, so it could have been just that, but still there does seem to be some way for the controls to get into a different order than what is in the code.
PS The name is a nickname based on my last name, I was not aware of the crator!
Interesting - OK, so I can theorize how what you’re seeing now is happening (I believe control order is loaded from a file, so once both the firmware is updated AND the pattern is saved (plus potentially a page reload in some scenarios), it seems to be resolved.
Sorry for the inconvenience and time spent troubleshooting! What are you working on?
After spending some more time with it Saturday, it still seems like there is not a reliably defined ordering (or there is something I’m missing or doing wrong). As I add and remove controls and switch between patterns, things keep moving around.
The project I’m working on is installed in a nightclub, and the idea is to enable the lighting guy to have a good level of control over it. I’ve only really just started customizing the programming and I have lots of ideas.
Here’s a video showing some of the different settings of two patterns I made:
Looks really cool!
Just so we’re on the same page, is it our shared expectation that the controls and their ordering are (well, can be) different for each pattern?
If so, a screen recording video of them jumping around could be helpful; I’m mostly seeing predictable behavior.
Thanks! Here is a video. It starts from a fresh boot after a week of use where no code changes were made.
For three patterns, the pattern is loaded on the Pattern tab, then the Edit tab is selected, the pattern is saved with no changes, then the Pattern tab is returned to. At this point the controls show as they did on the Edit tab, but selecting another pattern and then jumping back leaves them in a different order.
Regarding your question, yes. My expectation, or preference at least, would be that the controls for each pattern are in the order that they appear in the code, which is how they appear on the Edit tab. Currently I understand the ordering on the Pattern tab to be undefined or using some other logic.
ok, thank you - This makes it very clear, and I’m able to recreate it now, but only for certain bigger, already existing patterns. A new pattern with a few sliders reorders correctly every time.
I’ve made a similar video showing that contrast and sent to @wizard - we’ll see what he thinks. It’s odd, for sure. Thank you for taking the time to make the recording.
Sounds good, thanks. Yeah I definitely only started to notice it as I started adding more controls of more types on more patterns. I get the impression that the controls were added to allow a bit of tweaking, and building more complex interfaces might be beyond what they were intended for. Does that sound accurate?
Well, it doesn’t have a form builder or anything, but it probably should keep the order consistent and matching the order defined in code. I feel like it should be mostly usable for 1-20 controls, if a little busy on-screen.
Thanks for the details! Is it just me, or do some of the controls disappear? I’m guessing a bug snuck in there somewhere.
I noticed that in the recording not only changed order, but some of them were deleted. For example radiate first load shows a Random toggle, but this disappears in the editor.
I think one way of corrupting controls is if you are in the editor, and switch back to patterns and click on something, then back to the editor and hit save. This ends up clobbering the pattern’s controls with the wrong names, order, and values.
There also seems to be some other more nuanced issues just editing, perhaps some stale order information while editing similarly named controls.
In any event, in the videos from what I can see, it looks like clicking edit at least shows the correct controls names and order while editing. Let me know if that isn’t the case!
I have some fixes for these that should cover the nuanced corner cases, and will go out in the next update. Even if the saved controls JSON is weird, the names + order of controls should come from the pattern code names + order.
The issue when switching a pattern while editing is trickier, and it will clobber the controls data with something that doesn’t match. It should still load the right names and order though, and interacting with the controls will update the values properly.
It’s also possible that some browsers are using an older JS/JSON object key ordering spec (unspecified order) instead of the de facto and now official standard (creation order). There’s not much I can do for them unless I change a lot more and update the API, but at least any controls those browsers save won’t ruin it for any other browsers.
@wizard Thanks for taking the time to look into this, sorry for the delayed reply. I see the new release is out, will give that a test soon!
If the clobbering happens (and I’m understanding this correctly to be persistent/sticky), is there a good way to reset/realign the UI with the code?
As for the browser I’m using Chrome on Mac, let me know if there’s one that’s known to work better.
The new release should unclobber it. Chrome on Mac is fine.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
