Quote:
Originally Posted by hostar
|
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...