Quote:
Originally Posted by kaminkatze
I have a tinysh version that uses titty calls (initvar/eips -g for every key press). I guess with "to integrate it" you mean to merge both codes?
Scrolling and some other things that might be useful.
|
That code looks well done (and very interesting). I am anxious to use it as soon as I get some spare time.
By "integrate" I did mean to merge them. Although the linux philosophy is to have a bunch of small tools and pipe them together (which I *do* use for prototyping), keeping all the functions in one file prevents missing pieces or mixing wrong versions together. Scripts are "source code" anyway, so you can just cut and paste functions from a "master library" (or source the library, like how the kindle startup scripts source a "functions" file). But sourcing can lead to version conflicts too, and there is plenty of storage space for (complete) monolithic scripts.
BTW, I static link my C programs too (all libraries embedded in the executable), to prevent loadable library version conflicts between different kindle models. That works MUCH better for portable programs, to prevent missing or "wrong library version" errors when you run them on a different kindle model.
Being an "old-timer", I MUCH prefer larger programs and scripts that do not suffer "bit rot" as quickly as utilities that have external and version-specific dependencies.
EDIT: After integrating "tinysh" onscreen shell with "titty" tiny TTY, this new script should have a new name. I would name it something alliterative and easy to say and remember. I (strongly) suggest that we name it "kittycon" (kindle TTY console), and with a new name restart the version number. You can keep the history showing its parentage.
I plan to merge in GUI support from my other scripts (with buttons and stuff, and onscreen keyboard for touch and k4), so perhaps the name can later represent "kittycon - kindle tty control panel", making this name somewhat "future proof". I have been working on "gmcp - geekmaster control panel" occasionally for the past few months, but that name feels too egotistical, so I like kittycon "more better"... 
Of course, we should keep the individual functions as independent scripts as well (just like you did above), for direct use by other simple scripts, and for prototyping more advanced scripts. As I said, I like it both ways, but I usually *publish* tutorial demo code that I have stripped down to its essence, containing everything it needs (monolithic) but nothing that it does not use. 
P.S. Thank you kaminkatze for keeping this project alive and growing. 
