Custom KT UI without QT or killing nickle

[ichrispa]

Hi everyone,

there are many ideas out there on how to create own applications for the KT and integrating them into the UI. All I have found so far involve one of the following three points:

• Create an own qt embedded application. Requires to kill nickle and start the own app.
• Create a qt embedded plugin, replacing one of the extras (chess, notepad, sudoku) to start it from nickle.
• Using Python and pygame to create a standalone app.

I wasn't quite statisfied with any of them, because I do not want to get started on QT development. And I do want my normal UI to run... after all, this is a reader. So I came up with a new way I would like to share.


In my previous post about installing a webserver on the KT I elaborated on how it is possible to write php applications running on the Kobo Touch. Of course, these are accessible from the KT browser... though that is not really integrating.

Here's the next step: Redirecting the Webstore. Once I had the browser running on my KT, I wondered how the webstore works. It turns out that many pieces of the regular user interface are in fact webpages, displayed in a qt app using hindenburg (the KT's webbrowser). That goes for the webstore as well: What you see after accessing the store are in fact webpages... take a look at webstore.kobobooks.com - looks familiar?

You can control the address of the webstore. The last three entries in .kobo/Kobo/Kobo eReader.conf define the URL used when accessing the webstore.

I created my own page on the Kobo's local webserver (using shttpd, see previous post) to create the directory /71485/Search/Categories/index.php. Since the webstore is redirected to 127.0.0.1 as described in my previous post, calling the webstore now opens my own custom index.php.

This opens a new way to create a custom UI fully integrated with nickel without the requirement to modify the onboard libraries. It should be fairly Update-Resistend and in the end everything comes down to web development. Which in my eyes is easier to understand and modify than QT embedded applications.

A nice side effect: You can also access that Kobo UI from any computer in the local subnet... for example to take screenshots of the kobo.

I will post some screenshots of my little "Webstore UI" soon to show some of the possibilities given here. For starters, I am going to create the following extensions I miss:

• Rebooting the Kobo.
• Rescanning the onboard library by emulating plugging/unplugging of a usb host.
• A basic command prompt.
• Taking screenshots.
• An attic to store books outside the Kobos scanned directories (i.e. to hide an old newspaper).

As a note: php and sqlite to go together. I haven't compiled sqlite support for php yet, but after that one could modify the kobo's sqlite DB from an onboard php interface. Ever wanted to reclassify that sideloaded calibre book as a newspaper? Here's your chance ^^

Regards,

ichrispa

[jackie_w]

Hi ichrispa,

Good luck with your project

A screenshot ability could be a handy feature when trying to answer forum questions.

If you are able to safely update the sqlite database from the device UI then a good candidate may be the content_settings table which holds font-size, page margins and line spacing per book. Although the standard font setting sliders allow many values, they have not been particularly well chosen by Kobo (IMO) e.g.

• font-sizes - not fine graded enough in the mid-range. Jumps of 1pt would be preferable.
• line spacing - current minimum is 1.3, which is (IMO) too big for many fonts.
• page left/right margins - again not fine graded enough. Current values (in points) are 0, 3, 6, 9, 12, 15. Again, jumps of 1pt would be preferable.

Speaking purely for myself, I have no interest in web options, but there will be many who do.

[ichrispa]

Hi jackie_w,

changing the sqlite DB is never safe... it was just an idea. The commandline and some restarting features are of much more interest to me - but of course I want to also point out the possibility of customizing the UI as needed. The mentioned features are just the ones needed by me

EDIT: The screenshot capability would is actually there already. you can cat /dev/fb0 into the rgb565torgb program which I crosscompiled to run on arm. LibPNG is already crosscompiled, so I would only need to write some extra code to get a screenshot. Currently, this does the trick:

rgb565torgb < /dev/fb0 > convert -depth 8 -size 800x1280 -rotate 90 "$(date %Y%M%d-%H%m).png"

You need imagemagick on the kobo for that of course.
END OF EDIT

As promised, here are some proof of concept screenshots:

The Bookstore Interface on KT 2.3.2 should be known to everyone:


I hooked my UI in the Category page:



Which calls the local webpage on the kobo touch:



The page is interactive (though not very usefull for now). Heres the reboot button being pressed. The link in the image calls a php script linked as "system.php?action=reboot", which in turn executes the reboot command. I had to disable the action for taking this screenshot of course.



Yes, rebooting via interface is silly, since there is a nice comfy slider for that. Just wanted to demonstrate that my idea is feasable.

[jackie_w]

Originally Posted by ichrispa

Hi jackie_w,

changing the sqlite DB is never safe... it was just an idea. The commandline and some restarting features are of much more interest to me - but of course I want to also point out the possibility of customizing the UI as needed. The mentioned features are just the ones needed by me

Well, it was worth a try. I'm currently doing it via a klutzy SQL trigger, but a GUI would have been nice.

Originally Posted by ichrispa

EDIT: The screenshot capability would is actually there already. you can cat /dev/fb0 into the rgb565torgb program which I crosscompiled to run on arm. LibPNG is already crosscompiled, so I would only need to write some extra code to get a screenshot. Currently, this does the trick:

rgb565torgb < /dev/fb0 > convert -depth 8 -size 800x1280 -rotate 90 "$(date %Y%M%d-%H%m).png"

You need imagemagick on the kobo for that of course.

I'm afraid this is beyond my tech skills, my Linux knowledge is zero, but if someone ever writes a step-by-step or packages it into something simple and foolproof I'd be interested.

[ichrispa]

I'm afraid this is beyond my tech skills, my Linux knowledge is zero, but if someone ever writes a step-by-step or packages it into something simple and foolproof I'd be interested.

Well, taking a screenshot does require you to at least get telnet access to your kobo at some point. Even if a php skript does the "screenshooting" for you, you would still need to get it installed somehow.

There are really plenty of guides on how to enable telnet access to the kobo, incl. the mobilereader wiki.

You can get the raw screen content by issueing the following command over a telnet prompt:

root@kobo# cat /dev/fb0 > /mnt/onboard/screenshot.raw

After that the file screenshot.raw should appear if you connect your kobo to a pc via usb.

The steps you need to take next are more or less the same whichever way you go:

1. Convert the Raw data from RGB565 to RGB888 (8 Bit Raw image)
2. Convert that 8 bit raw image using gimp/ImageMagick/Python

I use the following script on my kobo to do convert a RGB565 Image to PNG.

#!/bin/env python
#
# This script convert the ARM Linux RGB565 Framebuffer contents to a PNG Image
# You need PyPNG and Python >= 2.7 installed to run this script.
#
# Use on your own risk

import png
import struct

RAWD = "/dev/fb0"

rawf = open(RAWD, b"r")
pngf = open("/mnt/onboard/.local/out.png", "w")

rawpng_flat = []
rawpng = []
pixel = []

data = rawf.read(2)
while data != "":
  r5 = (struct.unpack("H", data)[0] >> 11)  & 0x1F
  g6 = (struct.unpack("H", data)[0] >> 5)   & 0x3F
  b5 = (struct.unpack("H", data)[0])        & 0x1F
  r8 = (r5<<3)+(r5>>2)
  g8 = (g6<<2)+(g6>>4)
  b8 = (b5<<3)+(b5>>2)
  
  rawpng_flat += [r8%256, g8%256, b8%256]
  data = rawf.read(2)

png.Writer(width=800,height=600,bitdepth=8).write_array(pngf, rawpng_flat)

pngf.close()
rawf.close()

I have both python and pyPNG installed on my Kobo, so all I need to do is call this script via php to create a screenshot.

[koenieee]

Very nice to see this, brings a lot of simple possibilities to the Kobo.
How can I access this url: http://webstore.kobobooks.com/, because it gives me 403 forbidden. Do I need to change my user agent or something?

Nevermind, my KGlo uses another url. (http://webstore2.kobobooks.com/)

[ichrispa]

Mine KT uses webstore2 as well. I mistyped, sry.

[koenieee]

So now we can replace the Kobo store with something different? Such as an external Calibre library?

[ichrispa]

Originally Posted by koenieee

So now we can replace the Kobo store with something different? Such as an external Calibre library?

Sure. As long as it is html and fits on a kobo display, you can use it as replacement for the webstore.

I am still having some trouble with php. Notably, PHP works fine, but the Webstore somehow throughs an error when an HTTP POST or HEAD request is made. Still looking into that.

Please note: You still have to install the webserver on the kobo. I am quite willing to make the binaries available, but I will not put them in a KoboReader.tgz for auto installation.

[koenieee]

What is the problem with PHP? I now something about that, so maybe I can help..

[ichrispa]

What is happening is that I can start the integrated browser and point it to any address I want, incl. the onboard webserver. The pages need to be formated to fit to the screen, since there are no scrollbars and so on. I'll PM you an example of that, incl. your idea.

As long as these pages are html or generated via php, everything is ok.

I have tried to install several things, including my own php-shell (for issueing ad-hoc commands to the kobo). But everytime I submit POST or HEAD requests, the first click does nothing at all. When I click again, I get an "Ooops, something happened to the network connection" error. Sometimes the Kobo hangs itself after that.

I believe this is related to the webstore authenticating itself to kobo via a script called __utm.gif on the kobo server (which is requested during every UI interaction and includes many obscure paramters). The precice URL is http://webstore2.kobobooks.com/__utm...any=parameters
Since the Kobo thinkgs it's not authenticated, it somehow can't send POST's, as these would usually be purchases.