[Kindle Touch] Qt4: How To Use?

[wl.]

i saw the qt4 libs in some apps for KT, where to find info about compiling qt4 for KT, compiling qt4 apps, maybe on-device debuging?
sorry, i am newbie in kindle development, and no useful links in google. Point me please in right direction

[geekmaster]

Originally Posted by wl.

i saw the qt4 libs in some apps for KT, where to find info about compiling qt4 for KT, compiling qt4 apps, maybe on-device debuging?
sorry, i am newbie in kindle development, and no useful links in google. Point me please in right direction

The hard part is the eink support. Unless you call system("eips ''") to do the eink updates, it is a bit difficult to support all the kindle models with one program (especially if you want region updates to limit your updates to a small area like a character cell). Most qt examples here used the /proc update method, but that is not available for the K5(touch), and even 5.0.x and 5.1.0 are not compatible with each other, requiring separate versions of your program that only work on 5.1.0 or on everything EXCEPT 5.1.0 (unless you get a little more complex as is done in my gmplay-1.5 program, and even that cannot yet do region updates on 5.1.0). It is easier at this time to just call eips.

Even more difficult is keyboard input support (ony one key -- the HOME key). You need an onscreen keyboard. So, it has not been done already (AFAIK) because it is NOT easy or simple, and will require some development and testing to get working reliably on all kindle models (unless you WANT to maintain different versions for different kindle models).

Question: Which K5 (KT) apps did you see that use Qt libs? I would like to check them out myself. Up until now, I was not aware that there were any. I suspect they are restricted to a specific firmware version, OR they use an eips call for display updates...

EDIT: For compiling small programs, you can use tcc on the kindle. For larger ones, either use a cross-compiler toolkit (I use CodeSourcery), or install the gcc build tools in an optware loop mount on the kindle. Beware that there are severe resource limitations if you forget to stop the framework before doing a build (or even a simple wget) on the K5. Another option is to do your builds in a VM that runs arm code, but that is much slower than cross-compiling on the host PC. You can download CodeSourcery for linux or for windows. They both work fine (and much easier in windows if you configure the CodeBocks IDE to use CodeSourcery for arm projects -- and CodeBlocks also has a linux version).

[hostar]

wl.: Google for "qt arm".
For example try this:
http://www.qtforum.org/article/27787...om-phytec.html

[geekmaster]

Originally Posted by hostar

wl.: Google for "qt arm".
For example try this:
http://www.qtforum.org/article/27787...om-phytec.html

That is not "standalone". You would still need to update the eink after writing to the framebuffer.

The way it was done in an early Qt app from Jesse Vincent was to continuously do eink updates in a loop running in a background script, but to avoid eink artifacts, you really need that synchronized to the update cycle (see the VSYNC code in the gmplay program in my kindle video thread). It also saves energy to do updates only once, after each page creation is complete. That means you should add the eink update to the application (or to the Qt library).

You would also need some way to support user input, such as onscreen keyboard, touchscreen widgets, touchscreen gesture recognition, and perhaps mouse emulation. Otherwise your Qt apps are limited to output only, and there is not much point in using Qt just for output. There is a LOT more to this than just "./configure; make; make install"...

On the touch, framework-based apps are a lot easier (but not trivial). If you want "easy" start with an HTML5 app (like "Go" from cscat), or start at the other end with a simple C framebuffer app that you can compile with tcc. Look at the C programs (and "eink algorithmic art" scripts) from geekmaster and JoppyFur for simple framebuffer and touchscreen support in native mode apps...

@wl.: Which "KT" Qt4 apps were you referring to? Curious minds want to know...

[wl.]

Originally Posted by geekmaster

Which K5 (KT) apps did you see that use Qt libs? I would like to check them out myself. Up until now, I was not aware that there were any. I suspect they are restricted to a specific firmware version, OR they use an eips call for display updates...

for example: https://www.mobileread.com/forums/sho...d.php?t=175744

[geekmaster]

Originally Posted by wl.

for example: https://www.mobileread.com/forums/sho...d.php?t=175744

Hmm... his stuff is CLOSED source, some of it (like PBChess for touch) costs money, and when I installed his free sokoban for touch, it broke my launcher menu. Rebooting did not fix the problem. I could not even launch usbnet. At least the ";un" command still works.

EDIT: Perhaps you can just use the Qt libs included with sokoban? His free sokoban works pretty well, if I launch the script in the bin folder from ssh. I just ran strace on his sokoban, and he even has neon optimizations -- nice! It would be nice to see his eink and touchscreen source code patches to the Qt libs, being GPL and all... The libs are LGPL, but unless they have callbacks into his program for the touchscreen widgets, then he should provide source code...

[wl.]

Originally Posted by geekmaster

Hmm... his stuff is CLOSED source, some of it (like PBChess for touch) costs money, and when I installed his free sokoban for touch, it broke my launcher menu. Rebooting did not fix the problem. I could not even launch usbnet. At least the ";un" command still works.

it's bad, sorry for this. for me sokoban works well on both fw - 5.0.4 and 5.1.0 - buttons bottom when pressed don't blink all screen, and it looks pretty well.

ok, if native c++/qt4 is unstable, so better don't touch the sh_t atm. how about java? speed of java bytecode must be greater, than the eINK refresh rating. any success in this direction exists? "Hello World" in java?

[geekmaster]

The Qt libraries are probably NOT the problem here. If you want Qt and do not want to compile it yourself, feel free to use his. They are LGPL. The problem had something to do with installing it. The launcher is different for fw 5.1.0, and perhaps a file got replaced. I will just reinstall the new launcher (no biggie).

Here is source code and build instruction for qt (and a sudoko demo program) on the DX (perhaps it can be adapted): http://www.griffin.net/qt-and-sudoku...ndle-2-dx.html

[geekmaster]

The java used on the kindles uses cvm, which is claimed by some to be faster than jvm. And with the eink being the limiting factor, the language does not matter much. In fact, on modern multi-level cache systems, interpreted languages can actually be faster than native code if the interpreter fits in level 1 cache, because the code is more condensed and more of it can fit in cache (amazing but true).

[geekmaster]

Here is a "Qt for kindle" port:
https://www.mobileread.com/forums/showthread.php?t=94483

Of course, it depends on DX keyboard, so still needs touchscreen support added. Java would be a lot easier I think. Personally, I prefer low-level code (C and direct access to device driver ioctl() and /proc interfaces).

[knc1]

Originally Posted by geekmaster

Here is a "Qt for kindle" port:
http://code.google.com/p/qindle/

And installation instructions:
https://www.mobileread.com/forums/sho...t=94483&page=2

A qt-embedded for kindle according to the page link above.
(qt-embedded does not use x11 to drive the display, if uses the frame buffer display)

[geekmaster]

Originally Posted by knc1

A qt-embedded for kindle according to the page link above.
(qt-embedded does not use x11 to drive the display)

If you want to use x11, then you have all those window-naming rules you need to follow so the kindle does not hide your windows from you. But if you go below the framework, then it helps to pause the framework or capture the input devices. Whatever you do, you either need extra code for portability, or you will be locked into a specific kindle model (and even specific firmware VERSIONS on the K5(touch) thanks to recent undesirable update changes).

[knc1]

Originally Posted by geekmaster

If you want to use x11, then you have all those window-naming rules you need to follow so the kindle does not hide your windows from you. But if you go below the framework, then it helps to pause the framework or capture the input devices. Whatever you do, you either need extra code for portability, or you will be locked into a specific kindle model (and even specific firmware VERSIONS on the K5(touch) thanks to recent undesirable update changes).

Correct - the question "to use x11 or to use the framebuffer" is an important question.
Hence my note that the project linked to was a qt-embedded (framebuffer) and not a qt (x11) project.

I have not finished reading the changes the author has made, including any possible changes specific to the e-ink display.
The base is qt-embedded v-4.6

But this "dead project" may become significant in the "Kindle Explorer" thread.

[geekmaster]

Personally, I much prefer C over C++, so IUP from the lua creators is one of the few ways to go other than straight NIH from scratch.

Actually, for video games, I like "immediate mode" GUI, where you redraw the entire screen from scratch in layers for each update cycle. Instead of your screen consisting of a bunch of data structures that describe your screen layout with event callback functions, your "game loop" just calls a bunch of functions to draw all the screen elements, every time around the loop.

Event driven is better for saving batteries, and is great for "turn-based" games, but game loops with immediate mode GUI are much lower latency and much more responsive (no waiting for events), for action games like Doom, Quake, tux racer. My "goodbye" function buried inside the "newtrix" demo illustrates this "immediate mode" method, but it only animates the geekmaster signature object on top of the animated background. The signature could just as well be GUI elements such as buttons and sliders, but it makes animated backgrounds and animated GUI elements very easy to do. .

Here is a great little video about immediate mode GUIs (popular with Indie-game developers, and which I love to use): https://mollyrocket.com/861

And a nice little immediate mode GUI tutorial: http://iki.fi/sol/imgui/

I have enjoyed using this method in the past, and I plan to use it in my future code here. In my book, frameworks remove the "general" from "general purpose computers". What self-respecting cowboy programmer wants to follow rules laid down by some stinkin' framework limiting what you are allowed to do and how you are allowed to do it?

If you are going to let the COMPUTER tell you what you can do and how you can do it, then what is the point of jailbreaking it anyway? Just give me "bare-metal" root access and get out of my face, thank you!

Okay, you want Qt or Java you say? I will try to help figure it out as far as I can (such as providing links), but as far as using it in my code? Umm... no thanks.

[knc1]

Isn't post 14 a bit off topic here?

I can't see what your browser displays, but mine shows the topic title in the title bar of the window.