KTerm for Kobo?

[lordeagle]

Hi guys,

Coming from Amazon's Kindle world, I'm just starting to get warm with a Kobo Libra H20.

Has anyone built a terminal app to run for the kobo? On the kindle I like KTerm (https://www.fabiszewski.net/kindle-terminal/) in combination with a 'screen' session. Just to run a terminal on a device that still works in a sunny environment.

Any hints or posts that could guide me?

[NiLuJe]

The closest thing would probably currently be https://github.com/llandsmeer/inkvt

And my usual USBNet tools (e.g., tmux, screen & co) live in the Core KoboStuff package on Kobo .

[lordeagle]

Originally Posted by NiLuJe

The closest thing would probably currently be https://github.com/llandsmeer/inkvt

And my usual USBNet tools (e.g., tmux, screen & co) live in the Core KoboStuff package on Kobo .

Wow, that's definitively what I've been looking for.
Just played around with it and what I love most about it is the input from stdin mode. So I no longer need screen and the like ... but can directly use my keyboard.

With this setup, my standard use case is very well covered:

1. pair a bluetooth keyboard with my mobile phone
2. use Androids 'Termux' app to ssh into Kobo (usbnet)
3. create another ssh session from 'InkVT' to my real target client in the same net
4. so I can be almost anywhere out there: armed with a working terminal and no need for a powersupply to adminstrate whatever I want

Love it, thanks for the work to all involved.

However, being for the first time confronted with the need to build with the Kobo stack, I think there is a steep learning curve for those who just wan't to play with it. And many blockers for those who do not natively use a linux. So I try to share at least the ZIP which I've built today if anyone want's to try. I used it on Kobo Libra H20 (4.25.x) without major issues.

InkVT-f5ad15b.zip

[NiLuJe]

I'll try to avoid putting too much words in @llandsmeer's mouth here, but that's mostly by design: this should still be considered a WIP, it's only been tested on a few different devices, and we don't really have time to offer real support for it.

Requiring someone savvy enough to get their hands dirty to build it from scratch kinda ensures that, if support is required, it'll come from someone who has a vague chance of being able to actively help with the issue .

Given the use-cases and the target audience (it *is* a terminal emulator, after all ), that's a stance that I can get behind .

(I *have* tried to make sure the doc steers people towards koxtoolchain, so any and all feedback on that front if you hit a snag along the way would be appreciated ).

[lordeagle]

Originally Posted by NiLuJe

should still be considered a WIP, it's only been tested on a few different devices, and we don't really have time to offer real support for it.

I get the idea, and understand that the involved devs don't want to be flooded with too much noise around well known early prototype shortcomings.
However, it's also a missed chance to get early feedback around the most wished features/bugs from a larger user base.

Originally Posted by NiLuJe

I *have* tried to make sure the doc steers people towards koxtoolchain, so any and all feedback on that front if you hit a snag along the way would be appreciated .

Thinking it over again I think this is one of the rare occasions where I managed to compile c code. And I have failed in many other attempts. So the build is already very mature. I especially liked the responsive feedback and parameter exposure. So thanks for the good work.

I think, that it would have helped a little to have a shorter readme with fewer words, but the most recommended build/release commands at top. Including the commands to use koxtoolchain. ... and then following with the details later what it does and why we do it that way. Just give the user first what he needs want's to know first ... there has been a lot of smart good guidance on this in here: https://www.americanscientist.org/bl...ntific-writing
I'll try to fire a simple PR if I can make this more concrete.

Another idea would be to share a docker image with the koxtoolchain. On my weak consumer laptop the build process cost me around almost 30 mins. And I failed in the first attempt to run it as I have started the process on a disk with almost no space on it ;-)
... with the toolchain ready and in a container I don't have to dive into the topic and can just re-use the output of a smart build.

[sherman]

Originally Posted by lordeagle

Another idea would be to share a docker image with the koxtoolchain. On my weak consumer laptop the build process cost me around almost 30 mins. And I failed in the first attempt to run it as I have started the process on a disk with almost no space on it ;-)
... with the toolchain ready and in a container I don't have to dive into the topic and can just re-use the output of a smart build.

This is something I've been thinking about for a while. I already have a prototype Dockerfile (modified from one geek1011 provided for me in a github comment) that appears to work.

Just need to throw it up on a repo somewhere to get feedback, then an image can be pushed to a repository.

[NiLuJe]

Originally Posted by lordeagle

I get the idea, and understand that the involved devs don't want to be flooded with too much noise around well known early prototype shortcomings.
However, it's also a missed chance to get early feedback around the most wished features/bugs from a larger user base.

It is indeed a double-edged sword .

Originally Posted by lordeagle

I think, that it would have helped a little to have a shorter readme with fewer words, but the most recommended build/release commands at top. Including the commands to use koxtoolchain. ... and then following with the details later what it does and why we do it that way. Just give the user first what he needs want's to know first ... there has been a lot of smart good guidance on this in here: https://www.americanscientist.org/bl...ntific-writing
I'll try to fire a simple PR if I can make this more concrete.

Yep, writing good doc is hard .