That’s IMHO the way to go! Expand as much as possible the built in functionalities…
Here‘s the key difference compared to my position. When it comes to productive development my opinion on ‘the way to go’ is ‘expand as much as sensible’.
Without any doubt is it an interesting challenge to do coordinate transformations from ground up with only rudimentary integer math. In my opinion though, there‘s a clear difference between a challenge and productive development. If you buy a Nextion screen for the sake of having fun with it, then by all means, make it run Doom. Do all the crazy research, use all the neat as well as the dirty tricks and hacks - I’d love it. However, if you bought it for productive usage then you bought it to speed up development because that‘s essentially what you get for your money compared to a bare screen with a microcontroller. Ease of use; reduced dev costs (at the expense of higher part costs) and - very important - reduced maintenance costs because of reduced complexity. Often enough Nextion is a good choice for these reasons and makes a lot of sense (in case you forgot or missed it: I have pointed this out before). If so, then digging through research papers to find suitable algorithms, to then port them to Nextions restricted language, to get essentially a gimmick (more on that later) seems to me like you not only toss out any time, complexity and maintenance advantages out of the window, but also two grenades right behind to make sure nothing‘s left to even hit the ground.
Now some may think “what maintenance?? write it, test it, done!” Yeah, that works until you need to add some functionality (more steps f.ex), change some layouts, whatever. Especially in times of component shortages where the same product can easily ship with a dozen different board revisions it should be clear that changes are often enough unavoidable. And just to give one example where this slider solution adds maintenance costs/headaches: imagine you add a feature that requires/does a page refresh (ref 0). Well, great, now your slider doesn’t have a knob anymore. One more thing to keep in mind, one more thing to work around, one more thing that can go wrong. This is, no matter how much it bothers you personally, a disadvantage. From my own experience I’d say for the first hack like this you don’t care much, also not so much for the second. The third time you get annoyed and if you need to rework any of these you’re pretty much pissed of by the whole rat tail of certain changes. That’s my experience.
So my criticism - in this case - is less against the Nextion screens themselves but more against how it‘s marketed both by Nextion and also parts of the community. Claims like „look what you can do with a Nextion“ are in this context misleading because they imply it was (much) easier to do it on Nextion than f.ex. on a normal microcontroller. In reality, on the latter you simply write #include <math.h> and done. At least one hour of R&D time and money saved as well as a lot of headaches for the guy after you that has to work with your code base. This is what I want to get in the heads of people. If R&D time or money is limited, don‘t f*ing reimplement the standard C math library.
I called this circular slider thing a gimmick because in my eyes it doesn‘t offer any additional functionality compared to a normal slider. 90% is purely the visual, the something-else-than-standard-linear-slider. 10% is convenience for the layout because it might be more compact / space efficient in your particular layout.
If we were be talking about having a slider at all compared to no slider, I’d understand it somewhat more because the gain in usability would be quite significant. But we’re talking about replacing a normal slider that works just fine IMO.
As for my criticisms towards the technical side of Nextion, there are two that are related to this topic. One is simply the limits of the Nextion language. Some of them are really annoying and I cannot believe that there would be legitimate technical reasons to not change them except for the dev time. Example (there are others): no char to int “conversion” (there is nothing to convert ffs! A char is just a number so let me read it!).
For a long time we‘ve been hearing from the Nextion forum admins that this was (mainly) due to the STMs running out of firmware space. And yet they introduced a whole new TouchCap component, and yet they added a progress bar to the bootloader, … Something doesn‘t seem to add up here but please keep in mind that I haven‘t yet taken the time to verify what I‘m implying. Also, this argument gets (very) slowly less important because Discovery and Intelligent Series screens have significantly more flash than the Basic and Enhanced series.
The other one - and this really targets the whole „[enter any feature request here] can already be done“ argument - is the fact that anything you implement yourself runs on top of an interpreter which has a massive overhead (about a factor 3000). I did some benchmarks but I never took the time to properly document it here; so right now you need to trust me on these values.
No matter how you turn it, anything you do in the Nextion language runs three orders of magnitude slower than native code, so any fancy square root algo takes away precious time and thus responsiveness. Maybe except for the intelligent series, I would not say that the screens have an excess of processing power…
It is totally possible that in some cases it‘s faster to send values from Nextion to the MCU, process them there without interpreter-overhead, and send the results back to Nextion. That is just ridiculous (for me at least).
After this I hope you understand my position a little better. In my eyes Nextion isn’t just bad. But it’s not perfect either; and some people - including those at Nextion - seem to forget this sometimes. There is room for improvement and there are cases where Nextion is not the best solution.
Now, regarding my comment on their blog post. The fact that it’s not draggable wasn’t so much a criticism towards the blog post than a clarification for those that clicked your link that you posted in a thread with the title Touch draggable ring slider. For me at least, it makes quite a difference whether you can actually slide your slider or not.
You also seem to have missed my point about the “few lines of code”. Yes the solution is not very lengthy - never said that anyways. Also, I’m well capable of differentiating between lines of code and comments, but thank you very much for the reminder. The point was that just because it’s not 10 pages long doesn’t make it intuitive/beginner-friendly. Yes, again, the blog post does a rather good job explaining it, though it does hide some of the annoyances (f.ex. how to populate the LUT with values? Well you have to calculate them yourself. Looks easy and simple if they’re just written there but if you have to do it on your own it does make quite a difference - especially if you need more than a hand full of them).
In my head, a beginner (in the sense of: someone who has to ask a search engine about a “touch draggable ring slider for nextion”) that reads “oh it can be done with a few lines of code” likely expects little effort required compared to a normal slider - which would be the logical reference to compare with. And I think most of those people would be surprised in a not-so-positive-way what the “easy” solution looks like. But that might just be in my head.
But everything which isn’t acquired through blood, sweat, and tears isn’t worth anything.
This, sorry, to say, is utter bs. The amount of work and/or pain spent on getting a job done is not correlated with the quality of the result. In both cases you can end up with a beautiful solution as well as a steaming pile of sh*t. And no matter how much or little effort was required for a good solution, you can always be proud of it. If it took only little effort, be proud that you worked so efficiently. If it made you go through hell, be proud that you succeeded and didn’t give up.
Regards,
Max
Edits to fix the typos