View Single Post
Old 05-25-2012, 08:42 AM   #12
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by MaPePeR View Post
Thanks for the good answer, geekmaster.

If the keyboard is missing special keys: add them. its java, we can replace java functionality.
You can replace java functionality for java programs, but for compiled C programs such as this one, how can we use it in a simple and reliable way?

We could use a client/server method where a java "keyboard manager" program passes pressed keys to a native-mode (compiled C) program (perhaps through a shared file). But that is not simple, and may break on some kindle models or firmware versions.

I want my programs to run on all kindle models and firmware versions, with little or no awareness of WHICH kindle they are running on. I keycode differences by detecting the model only during program initialization and selecting a keycode translation table for later use. I also select which kind of eink update calls to do during initialization. The main code body should not care which kindle it runs on.

P.S. The best thing about standards is that there are so many to choose from.
geekmaster is offline   Reply With Quote