WolframAlpha app for Kobo - and some Python stuff (keyboard, touch input librairies)

[Mavireck]

Hello everyone !

For the last couple days I have been working on a project which is still widely in development.

And here it is now : a WolframAlpha app for Kobo.


It is based on @sherman's work which was originally written in Go. I ported it in Python and made a wolfram app with it.
Sherman's work include a few interesting code in Go (available in his github) :
- an on-screen-keyboard (osk)
- some script to use the touch input more easily (Kobo input)
I ported them to Python. These are the osk.py and KIP.py file.

Here is the Github page for the Input librairy :
https://github.com/Mavireck/Kobo-Input-Python
And the Github page for the on-screen-keyboard and a few useful functions (like a popup and a prompt function that display directly on the Kobo screen) :
https://github.com/Mavireck/Kobo-Python-OSKandUtils

Here are the sources:
https://github.com/Mavireck/Kobo-WolframAlpha

INSTALLATION
Unzip the latest zip with "WA" in the name at the root of your sd card.
You need to have KFMon and NiLuJe's KoboStuff installed.
https://github.com/Mavireck/Kobo-Pyt...ncher/releases

IT HAS ONLY BEEN TESTED ON H20 v1. Use it carefully.

My TODO list : (which I won't do entirely probably, as I won't have much free time in the coming year)

Spoiler:

- Make it cleaner
- (easy) Add a visual indicator for keypress
- change the key layout after a press on the Alt key to access more characters. (and change the way capslock works too)

Have fun !
And don't forget to thank sherman for his hard work in go !

[Mavireck]

I forgot to mention one important thing :
All this rely on NiLuJe's FBInk and Python. Thank you for your work too!
Also, in terms of copyright, as what I have released is based on sherman's code, it follows the same copyright.
I will publish it on github after I clean up all the mess in the code. I was just too impatient to share with you what I have done already!

(it looks like I can't edit my previous post. Is it because I am a Junior Member?)

[NiLuJe]

Just a quick note to mention that KoboStuff bundles FBInk, so, no need to install the standalone FBInk package .

[Lucas Malor]

Why you ported it in Python?

[Mavireck]

Originally Posted by Lucas Malor

Why you ported it in Python?

Well...
First, that is a language I know much better. I had never read Go before, and I do not want to delve into it for now. (I do not have much free time these days). Furthermore I need to master Python for scholar purposes so I thought it would be a fun way to learn this language.

NiLuJe provided python bindings for FBInk, so I thought that would be nice to have more sources and code written in Python for everyone to use.
I published it with sherman's authorization.

[Lucas Malor]

But you can't simply get the source code in Go, compile it for an ARM machine, and run it?

[Mavireck]

Originally Posted by Lucas Malor

But you can't simply get the source code in Go, compile it for an ARM machine, and run it?

I will answer honestly : I have no idea how to do that.

The advantage of porting the code is that you can more easily use it. Adjustements and fixes are easy to make.
When I talk about a touch library, my port defines a new class which can be used in Python code. In your Python code you just define a variable from this class, which simply sends you the coordonates you clicked on. That is very easy to use this way.
And for the keyboard, the reason I did that was curiosity. I found the way it was coded very elegant and I used many tricks from it in my other project.
Oh and porting these scripts was not that long, these are small files!

Then, I used these two librairies to create my wolfram alpha app. I built this app completely on my own (that is not a port)

[geek1011]

Originally Posted by Lucas Malor

But you can't simply get the source code in Go, compile it for an ARM machine, and run it?

It's not as easy when using fbink, as it needs a cross-compiler for cgo to work. But, personally, I do think using go is easier than setting up python, unless you are using Windows (cross-compiling to Linux is a huge pain).

[Lucas Malor]

Well, you don't need to cross-compile. You can simply create and use an ARM VM. I think the result it's also more reliable.

The problem of forks is the maintenance. What if the original maintainer continues to add features or bug fixing? You'll report all the changes every time in Py? And what if you abandon the project?

[NiLuJe]

We're all forgetting that input handling is essentially a main loop, so, err, having a main loop in Go for a Python app kinda doesn't work ^^?

The OP would have had to write everything in Go, which is another argument entirely .

The whole point of my Python packages is to leave the painful crap to me, so that devs can just start hacking on their code right away (i.e., quicker iteration).
The only downside left is the dependency on said Python packages (vs. a standalone-lier approach in Go or LuaJIT or C).

[Mavireck]

Originally Posted by Lucas Malor

Well, you don't need to cross-compile. You can simply create and use an ARM VM. I think the result it's also more reliable.

The problem of forks is the maintenance. What if the original maintainer continues to add features or bug fixing? You'll report all the changes every time in Py? And what if you abandon the project?

Well the problem of maintenance is a good point, although to be honest the code is simple enough for everyone to understand it and fix it. The script which sets up the input is only about 200 lines long...

It's not as easy when using fbink, as it needs a cross-compiler for cgo to work. But, personally, I do think using go is easier than setting up python, unless you are using Windows (cross-compiling to Linux is a huge pain).

I am using Windows and that definitely makes the testing process very easy : one file to drag and drop through FTP, and 2 commands via ssh to start the scrit.
It would have required much more work to code in GO I guess.


Perhaps has my first post been too ambitious: at first, it is only about me publishing a WolframAlpha app for Kobo. I just added that I ported a few scripts to Python if anyone wanted to use them, without any guarantee.
I definitely think the main problem when starting to code on the Kobo is the lack of help and documentation.
I have no experience in writing such a code. I have learnt Python at my engineering classes to solve math problems mostly. I do not have a good Linux background, and I keep terrible memories of the time I tried to compile things in a console.
Therefore, the FBInk librairy was to me a dream coming true : an easy way to print things on a screen in a language I know. Then, it still lacked an easy way to deal with the touch input. I saw sherman's script in Go, ported it in Python so that I could use it easily.

Now, honestly, I find it very easy to build a Python app for Kobo : use the power of KFmon to start it, FBInk to print on the screen, and if you need touch, use my script.
The same could be done in Go, through sherman's work. I just don't know Go and don't want to learn it yet.

If you don't think posting this app here is of any use, tell an admin and delete it I am fine with it ! I only wanted to share the product of a few hours of work...

[NiLuJe]

Nope, that's definitely the spirit, don't get pressured into thinking it isn't, that'd just be a shame .

(You clearly introduced this as a quick weekend project, there's really no need to get anyone's knickers in a twist ).

[Lucas Malor]

Originally Posted by Mavireck

If you don't think posting this app here is of any use, tell an admin and delete it I am fine with it ! I only wanted to share the product of a few hours of work...

Hey, who said that? I think you've done a good job, I have only some concerns about the maintenance of the code.

[Lucas Malor]

Originally Posted by NiLuJe

We're all forgetting that input handling is essentially a main loop, so, err, having a main loop in Go for a Python app kinda doesn't work ^^?

The OP would have had to write everything in Go, which is another argument entirely .

FBInk is "only" a library or can be invoked as command line module?

[NiLuJe]

@Lucas Malor: Both.

But if you're writing in a language where bindings are available (currently Go, LuaJIT, Python) (or, obviously, C/C++), going the API way is obviously preferred .

(Especially for stuff like this, since you gain access to fbink_print_raw_data(), which allows you to avoid useless encode/decode/storage passes when you're dealing with dynamic image data).