As is stated there, i can't move element via modifing "black parameter".
So my feature request is to make it possible :)
I do not want to create nice movement animation or so, but simple move one element to other place.
Even if reload of page is necessary after moving, it isn't that bad.
But of course if moving in loop would be possible, it would be nice :)
I know i can duplicate it and hide/show, but for more elements its get more complicated and unreadable in editor.
Yes, it does boil down to money - budget allotted to components.
For example, I imagine what processing Nextion could do if it used my Edison for its MCU.
And what kind of awesomeness you could add to your cam-on-rails with an Edison.
But on the STM/GD MCUs, a read-write attribute column, means sram on all.
This is why I complained about the .pw attribute already user capable
- as it stripped sram and attribute resources on every text component
(even though only one, or max two text components would ever use .pw)
Im also thinking about xcen and ycen for example. It's wasting space.
Correct me, but we talk about 4 bytes per one movable element. Or 4 bytes in flash to store x/y is static/dynamic and 4 bytes in sram IF element is movable.
It isnt that much.
so that is already 12 bytes per component - not one component, all. Whole column of table.
.pw attribute was more simple, column only used by Text Component
.key attribute - only used by Text, Number and Scrolling Text.
.x, .y -> Every component (Including Variable and Timer to save space of coding logic)
Easy test is this.
When we as users can show it working in an RBT6 with all Nextion Functions still in tact.
Then maybe they have an alternative to consider.
Until then their brain power will make their attempts.
I mean 4 bytes more than now :)
It is not a mere 4 bytes. Without coding logic it is 12 per component.
Such coding logic to have such reduced to 4 bytes will most likely exceed MCU flash
Right now such coding logic is not needed, it was prevented in Editor Build process.
I tried to "pic -x" or "pic >screenwidth" and nothing bad happens. So this can be driven exactly same.
Of course touch can't work offscreen :)
Creating new type of element is backward compatible, and prevent from sram consumption. New type could be like text/button with in-run editable position and text (and visiblity).
So perhaps users demonstrate how this can be accomplished in an RBT6 and retain Nextion capabilities and he has an option to consider.
Until then, his team will work towards if such a solution is viable.