New post to GitHub contains an update focused on constraining text input to visual bounds. When you type text in what looks like a text field, the text does not bleed outside of the text field. The update can be found on GitHub at around 11:51PM EST 2/1/2018.
A great answer to the question, “Did the programmer with the most lines of code, do the most work? by Bill MacDonald“. There is more to code than lines written. This answer from a software engineer at GoPro gives a glimpse into the world of debugging, analysis, and testing.
A new update is available with some performance improvements in keyboard typing. The keyboard behavior is important that is an area highly dependent on timing. The current version posted to GitHub uses a basic polling method. The plan is to apply a time interpolation method to saturate a queue before releasing the buffer to the screen. That will come later during an optimization phase. I also consolidated the text buffer representation to a common class type to facilitate buffer switching. Added implementation files for some header only classes in preparation for expanding their functionality.
If we have to continue to live with the x86_64 architecture in light of Intel’s Plans To Release Chips That Have Built-in Meltdown and Spectre Protections Later This Year, then could we consider the possibility that processor performance is not everything? What’s better a CPU that is fast and allows hackers to breach sensitive data faster or a far less vulnerable CPU in which the programmers have more responsibility for speed due to choice of algorithms? Perhaps too much has been offloaded to the abstractions provided by the CPU and a more basic but dependable CPU would serve the interests of data security better.
Generations of pushing the ideology to put more trust in very high level abstractions shows that approach does not always bear fruit regarding some kinds of software infrastructure. The news that Ubuntu 18.04 LTS Will Default To The X.Org Stack, Not Wayland amounts to the abandonment of Wayland by its largest sponsor. An anonymous poster to that article summary noted that X11 is 40-years field tested on everything from 386 running in the low MHZ to present-day. Replacing that was not a trivial task. Sometimes a new abstraction has to get all the details right to replace an incumbent.
The program now reflects text input that includes special characters such as !@#$%^&*()`<>?:” that was not being handled by the Allegro 5 Game Programming Library (AGLP5). The AGLP5 system detects keyboard actions but only provides a function that tells you the name of the key but not the actual value of the character in most cases. The text character event doesn’t work at all (or may depend on the operating system used or a API setting documented elsewhere). Instead, I detect key presses and translate them into text character values. That was okay but the lack of character translation was not ideal. Despite reservations, I added a function name al_get_char_from_keycode that takes the AGLP5’s keycode from the Key Up/Down events and an indicator if shift or caps lock is active and returns a character.
The current version of the C++ code that has this sequence is available as the 1/21/2018 commit to GitHub. I looked at using Gainput as a drop in substitute for AGLP5’s tracking of keyboard entry but did not like the build approach for Gainput. I prefer libraries that use a single configure script from GNU Autotools when building on Linux. Next, I tried SDL and succeeded in getting SDL (you know, the code library used to make Angry Birds) mixed into the program but quickly realized you couldn’t just use the keyboard part without also initializing the video subsystem. Anyway, I am satisfied with the level of text support in the program now but learned that is a deficiency in AGLP5 that I’ve worked around but merely for the US English alphabet.
The next step with text input is to handle clipping the text within the text field’s display boundaries. I will have to simulate the continued input of text by implementing the appearance text characters on the opposite end of the text field moving away from the text cursor once text exceeds the width of the text field. Also, I need to put in backspace, delete functionality, cursor vertical line placement and a several other little details. Defining a text field from scratch rather than using it as a prepackaged widget reveals much about the qualities of input concepts often taken for granted.
The newest update finally has near operable text fields (working on handling special characters). Added in a little highlight when a given text field is clicked. The latest commit on GitHub for this one also reworks interactive state persistence.