Our story begins on a stormy winter night in January 2017,
just shortly after New Years ....
Great surprise today to find that the Nextion Editor has been updated to version 0.42, including some keyboards for text an numeric input. Fantastic!
Even greater surprise to find that the qwerty editor is missing the "T" key.
Thanks a lot for the update but how such a gross error went through?
thats not a bug of the Editor ...
All keyboards are nothing more than HMI template pages ... just import the page, unlock it, and edit it to your needs ... and export it again ...
That template is part of the editor distribution and there's a bug on it. The fact that the bug is not in the executable file of the editor is just a technical detail which is irrelevant for the user.
Are you proposing that every single user out there develop his own fix for this bug?
maybe instead of complaining you also can fix it and just post your fix in our Gallery? Then it is even public available ...
We surely will do enhancements exactly on this way, and it is up to the user to come to the forum and update by himself when something is available ...
Especially on this way we introduce an easy way to enhance and update single components without reinstall the whole software ...
I'm not complaining, I'm reporting a bug. Most companies appreciate bug reports and do something about it. It seems this is not the case.
Pitty there is no button to down-vote a comment, but I'd agree that this is a valid bug report and post #2 could be suggested as a workaround, but post #4 is not what one would accept as a reaction to a bug-report.
So, here is the skinny and my explanation. The T was reported already.
The New Feature of sharing HMI code via page import/export arrived in v0.42
So to showcase this new feature, a user contributed code was used
How unfortunate that this user's code was missing a T
But I would be really so cautious of complaining about user contributed code.
I don't think many take well to their code being ridiculed (even if a mistake was made)
Complaining about user code does not motivate the community to contribute code.
What should have been taken away and recognized is the page import/export.
The ability for users to share their code via pages and not having to cough up whole HMIs.
Now in the case of the missing T, it can validly be argued by the contributing user that
There is sufficient code and techniques showcased that the end user receiving the shared code can modify to suit their own needs.
And this is true, certainly there are many visual adjustments that can be made and each suited
to the end-users taste. The font is wrong, the keys visually unappealing. Are each of these now a BUG? If I want Function Keys, is it a BUG they are not there? So a missing T is not necessarily a BUG.
We will now enter a new era where there will be much more code sharing via this import/export.
There certainly will be no tolerance of demanding user shared code be adjusted to another users
tastes when the user has the code to adjust it themselves. User coding errors is not a BUG.
For those old enough to remember shareware, you can test some other's code, and if you like it - then fine, that is good, and if you don't like it, you don't need to use it. And you keep looking until you find something suited to you - or modify the code to suit your taste and republish (assuming right to).
But I might certainly refrain from crucifying the first user contributed code in this fashion. When your code is posted in the Gallery or Free Chat, I will certainly not be tolerant of users bashing other user's code because it doesn't suit another user's needs - no matter how blatant the mistake maybe - simply choose not to use it and no need to upvote if you so chose not to.
For now, the end user IS capable of modifying the code. Perhaps in this case this user may make a correction, but it would also be correct that the user say the contributed source contains sufficient techniques for the end-user modify. It would be also a correct answer that the end user swap the corresponding page file containing the missing T with an HMI page file designed by the user which then contains the users own keyboard, with visual appeal and functionality so desired by the user.
The chosen font of the keyboard examples is also NOT a BUG, nor is the visual appeal.
So a missing T in a QWERTY keyboard is not a bug. Ok. My apologies for confusing such an extravagant feature with a bug.
I don't think I have ridiculed anybody's code. I just reported a bug, a blatant one in my opinion. We all make mistakes but apparently not everyone reacts the same when they are reported to them.
If this keyboard is user contributed code, it is not attributed or credited as such in the release note. I'm 100% sure that if I could have reported the bug directly to the author he/she wouldn't have responded "go fix it yourself".
Anyway, it's a great upgrade. The page import/export feature is very useful and the possibility to modify the keyboard to your needs is really nice. Thanks for that.
Yes, I agree Qwer y is indeed noticeably off.
But in the interests of keeping this new found code sharing capability alive with the momentum it deserves, it is so important that we look past the case of the missing T to realize what we have been given to make use of.
I for one will definitely want to:
1) make my keyboards that are suited to the visual style of my project. This will involve a complete visual rework of the presented keyboard and many keys will need to be added as well. A missing T does not effect this.
2) Tutorials will be much easier with loading pages that come with their needed resources.
3) Anyone look at the code of it yet?
a) The b[.id].attribute component array is officially used
b) The p[pageno] array is introduced and is used in conjunction with the b[.id] array
4) The .key attribute will show its usefulness in more than one way
5) page locking ..
6) the import page introduces background none - transparent popups or overlays.
7) and more we have yet to discover.
Very nice fixes in v0.42,
- color entry by number - so thankful
- HMI color pallet is saved for 16 color
- HMI used colors in quick select - great for theme and skinning
- My CPU fan isn't screaming, less CPU usage
There are so many applications of these to make life much easier and extend Nextion.
Personally, I am going to overlook this T in favour of all else it brings and hope that
this first community response to shared code via pages does not stunt others from
wanting to create and share with the community.
[Please don't take this post as a personal attack, it's just a few comments :-) ]
@Michael - Thank you, appreciated.
- perhaps this error helps spur the intended page sharing objective.
the p[pageno] array is new to v0.42.
Yes, if I had a general mistake, I too would want to know about it.
- had the layout been empty of characters for users to fill it in, it
would have had a better reception "Oh look, I could use this for ..."
- I think it is an embarrassing situation for the one who made it
- Had the U key been the missing one, perhaps not as bad
- But certainly all the effort that went into it was less addressed
- I didn't want any lynching, but more applauding the effort.
- I don't want users to feel shy about attempting to share via pages
- this aspect could really help the Nextion community
And in the spirit of remaining positive, I think there is a difference between
"Ummm, Yo ... like did you know a key is missing?"
and the way the thread started. Thank you for keeping it more positive.
I hope the users find that I have been helpful, honest and open,
- being a voice for the users was my intention.
I'd say that the title given to this thread, "T missing in default qwerty keyboard" is accurate and non-judgemental.
I'd also say that it was entirely unclear to me that the keyboard was either user-submitted or an example of the page import/export feature.
Anyway, kudos to itead for a very useful update. Kudos to the unknown user for making a keyboard example available (even if imperfect).
Now, is there a replacement for this keyboard example which will work on all Nextion sizes? How would we import it so that it shows in the "key" attribute of appropriate objects?
I am assuming a fix is being created. But I am assuming.
The keyborden folder has all sizes and orientations
1.page is full keyboard
2.page is numeric keyboard
3.page is speed dial keyboard
So replacing each of the 1.page would replace all full sizes
Michael has also made a qwerty keyboard in the Gallery
Several are working on one including myself
I doubt anyone is creating for all sizes
But I imaging as a community, there will be enough made
from the user base to have one in each size or orientation
Of course, all will probably have various differences and abilities