Hi, just a heads up for those owning a Kindle Touch, Paperwhite or Voyage: There is a gargoyle port for these Kindle models. Requirement: the device must be jailbroken. Here are the links:
A port to Kobo e-readers is unlikely, since AFAIK Kobo e-readers only provide the qt-embed GUI libraray, whereas Kindle provides GTK 2.0, on which the LINUX variant of gargoyle is currently based on.
I can’t tell you that, I am not one of the maintainers of the main gargoyle project. I did however submit the git & glulxe update merges as github pull requests, whether the maintainers will accept them or not, I can’t tell.
I tried to post the following message to the garglk-dev google groups mailing list, but for whatever reason my 2 postings (posted 1 and 2 weeks ago), didn’t show up, that’s why I post this here trying to reach the maintainers:
I maintain this repo: github.com/poker335/garglk, that contains the gargoyle port for Kindle Touch, Paperwhite, Oasis & Voyage.
The changes to garglk master are:
Kindle Port based on patches from: fabiszewski.net/kindle-gargoyle/ . Uses different GTK 2 UI elements for dialogs (the standard gtk2 dialogs don’t work well on the Kindle’s low resolution screen). Configures gargoyle to start in fullscreen mode. I integrated these Kindle changes, so that the Kindle specifics can be selected at build time, by specifying -sKINDLE=true.
Kindle Port incorporates a fixed (fixes: work in progress) version “double click/double tap on word to insert” patch from: github.com/RedHatter/granite
Kindle Port maps swipe up / down on touchscreen to page up / page down in the text window.
Planned features (especially since the Kindle’s on-screen keyboard doesn’t offer any cursor and/or control/alt keys): Enable positioning input cursor by tapping/clicking on input line.
I consider these changes sensible for any smaller resolution touch device.
Would you consider to integrate this port into the main gargoyle repo? Or should I continue to maintain it as a fork?
I currently also supply the binaries for the most recent firmware (5.8.9), as well as for older models running on older firmware versions (Touch & Paperwhite 1).
I don’t see any reason why the Kindle port shouldn’t be part of the main repo.
At the moment we’re stumbling toward a new release, so I don’t want anything potentially breaking to go in, but if the Kindle stuff is self-contained (i.e. only built when the Kindle port is being built), then there’s no harm in getting it in earlier rather than later. Feel free to submut a pull request in that case.
No, unfortunately I don’t know of any native GTK App that achieved this on Kindle. The standard Kindle framework runs in (some ancient) Java, and accessing that framework and its features is not well documented at all.
What could be done without much effort is to implement a context menu, that opens when you do a “touch & hold” gesture, like kterm implements it, screenshot: http://www.fabiszewski.net/kindle-terminal/ (kterm = terminal emulator for Kindle).
KOReader for Kindle has something similar to the Kindle’s top-menu, but it is an implementation they did themselves, and they use a different programming language and possibly GUI framework.
I was rather focusing on things that could be done easily, and that enhance my personal usability experience, so I focused on “glueing” touch gestures offered by the used Xorg touch driver to already existing gargoyle functions. Without that, I found editing the input line to be a pain, because the Kindle’s on-screen keyboard lacks any ctrl-keys and cursor keys, nor does the GUI framework support exact touch based cursor positioning (like the magnifying glass in iOS).
I would like to use this for word suggestions, but the on-screen keyboard’s API is not open (as could be expected).
Still, I am now quite happy for my personal use. Next step would be to clean up the implementation to be able to send a pull request to the main gargoyle project. Only after that would I look into more features.
perhaps we could come up with some gesture and a “are you sure?” prompt to exit/kill the app? Even some odd sequence like touching all 4 corners in under 10 seconds. Then there would be no need to deviate in the visual side from what is there now.