Kobo Dashboard (Another not-so-useful app I made)

[NiLuJe]

@Mavireck: That was kind of the idea behind the dump/restore API (c.f., @sherman's original FR [and my ramblings ;p]).

At least as a backend for that kind of thing, possibly coupled with print_raw_data for more esoteric use-cases.

I vaguely recall seeing you use the dump/restore API before, so I'm curious as to what led you to stick to print_raw_data for this?

(That's a perfectly valid solution, mind you, just asking in case something can be done to make the dump/restore stuff more approachable/practical ).

[Mavireck]

Originally Posted by NiLuJe

@Mavireck: That was kind of the idea behind the dump/restore API (c.f., @sherman's original FR [and my ramblings ;p]).

At least as a backend for that kind of thing, possibly coupled with print_raw_data for more esoteric use-cases.

I vaguely recall seeing you use the dump/restore API before, so I'm curious as to what led you to stick to print_raw_data for this?

(That's a perfectly valid solution, mind you, just asking in case something can be done to make the dump/restore stuff more approachable/practical ).

I did use your dump and restore API before. It is working very well, and I had absolutely no issue with it!
I can't see if a way to improve it, it is just that I needed something much more powerful than only dumps and restores

For my dashboard, I needed at some point to update an image which was partially hidden by another one. The problem is, I did not quite have an easy way of knowing how the area they occupy intersected each other. (and it is more and more of an issue if you have a lot of items on screen). Instead of coding it manually for every single situation, I sat for a few hours to make KSSM, which does all that for you

In short, dumping and restoring works great as long as your app remains small, but after that it gets more and more complicated.
If you don't believe me, have a look at the test file, with the 3 rectangles thing.
If you can, try it.
It is extremely easy to use, but I could not think of an easy and general way to do the same thing with dumps and restores (or at least, not such an easy way)


Also please note that it is still widely WIP, one day ago it was only in my head

[NiLuJe]

@Mavireck: True, I definitely get that for more complex setups, it can get hairier .

(And, no matter the state of the code, seeing what people do with it is a great way for me to tweak stuff, hence my pesky questions ;p).

That said, you do have access to a dump's width/height & position, so it should be usable for clipping detection, too. (Unless I'm missing something obvious, in which case, do remind me ).

Looking at the code, I can somewhat understand that once you start chopping rectangles up in little bits, being able to crop stuff starts coming in handy .
That was indeed left to the user (and it can get a bit tricky when you want to do it in-place with only a memory buffer on hand), so I added support for that to the dump/restore API, since it was already messing with pixel formats and memory buffers internally, and the "metadata" needed to do it right was mostly already all there .

EDIT: ... Which I've just fixed ;p. Not quite sure if it's more usable this way than via an FBInkRect to handle the crop settings...

[Mavireck]

Originally Posted by NiLuJe

@Mavireck: True, I definitely get that for more complex setups, it can get hairier .

(And, no matter the state of the code, seeing what people do with it is a great way for me to tweak stuff, hence my pesky questions ;p).

That said, you do have access to a dump's width/height & position, so it should be usable for clipping detection, too. (Unless I'm missing something obvious, in which case, do remind me ).

Looking at the code, I can somewhat understand that once you start chopping rectangles up in little bits, being able to crop stuff starts coming in handy .
That was indeed left to the user (and it can get a bit tricky when you want to do it in-place with only a memory buffer on hand), so I added support for that to the dump/restore API, since it was already messing with pixel formats and memory buffers internally, and the "metadata" needed to do it right was mostly already all there .

EDIT: ... Which I've just fixed ;p. Not quite sure if it's more usable this way than via an FBInkRect to handle the crop settings...

You are extremely reactive for improvements!
I will think about it, to see if I can improve the code clarity or performance using cropped dumps. But as far as simplicity and clarity are concerned, I think print_raw_data is more than enough for my use

[NiLuJe]

@Mavireck: Fair enough . Thanks for the feedback!

EDIT: I forgot to mention that print_raw_data *does* honor is_inverted (unlike restore) . The input data itself won't be touched, but what's written to the fb will be inverted.
(While with is_nightmode, the data is written as-is, and only inverted at refresh time by the EPDC, without affecting the fb).

EDIT²: In some circumstances, you can also do a batch of prints with no_refresh enabled (so they don't actually trigger an eInk refresh, but are written to the fb), and finish the batch with a manual refresh call (thinking of printing a stack from bottom to top here, for instance ).

[Mavireck]

Originally Posted by NiLuJe

@Mavireck: Fair enough . Thanks for the feedback!

EDIT: I forgot to mention that print_raw_data *does* honor is_inverted (unlike restore) . The input data itself won't be touched, but what's written to the fb will be inverted.
(While with is_nightmode, the data is written as-is, and only inverted at refresh time by the EPDC, without affecting the fb).

EDIT²: In some circumstances, you can also do a batch of prints with no_refresh enabled (so they don't actually trigger an eInk refresh, but are written to the fb), and finish the batch with a manual refresh call (thinking of printing a stack from bottom to top here, for instance ).

I am always surprised by how many things are already integrated in FBInk... It should be used by more apps!
About is_inverted and is_nigthmode, is there one which is faster than the other?
As for the no_refresh, I forgot about it, so I did it completely differently : my change
The advantage being that if one day I am to port this to another device or another library, it will be easier (because I use less-specific functions). I do at some point planned to separate what is general (the stack manager logic) from what is device-specific (FBInk functions, refreshs etc...).
That should make it easier if one day I want to port my apps to android for instance, or whatever device.

[NiLuJe]

Technically, leaving it to the EPDC (i.e., nightmode) should always be faster .

In practice, software inversion is fairly cheap in most cases (especially on a Kobo, since they're never @ 8bpp on their own).

[sherman]

What a fascinating series of posts. I've been thinking about GUI toolkits on Kobo's for a while now, investigating different strategies.

Ideally, something like littlevgl, Dear Imgui, or nuklear could be quite nice to use, although they all have their pros and cons.

Littlevgl looks easily portable to different devices, but its event handling seems to be tied to a refresh rate/polling mechanism.

Dear Imgui looks nice, but it's C++ and designed for OpenGL, although there is a software rasterizer that has been developed for it.

Nuklear also looks quite nice. It too is OpenGL, with a software rasterizer that has been written. It's a single header library, which makes for easy deployment. Main issue is the font handling seems very convoluted to get started with.

Another thing I've been mulling is the idea of making my own toolkit, very much like KSSM here (although probably in Go).

[NiLuJe]

Yeah, I vaguely looked at nuklear (at a glance, for a simple "what could be done" PoV), and, AFAICT, we'd "just" need basic primitive drawing capabilities for the software rasterizer (i.e., lines, circles, polygons & co. Currently, FBInk makes do with flat filled rectangles only). Didn't look at the font handling at all, though .

I don't have any urgent need for a GUI anywhere myself, but that was interesting stuff to look at .

[Mavireck]

Originally Posted by sherman

What a fascinating series of posts. I've been thinking about GUI toolkits on Kobo's for a while now, investigating different strategies.

Ideally, something like littlevgl, Dear Imgui, or nuklear could be quite nice to use, although they all have their pros and cons.

Littlevgl looks easily portable to different devices, but its event handling seems to be tied to a refresh rate/polling mechanism.

Dear Imgui looks nice, but it's C++ and designed for OpenGL, although there is a software rasterizer that has been developed for it.

Nuklear also looks quite nice. It too is OpenGL, with a software rasterizer that has been written. It's a single header library, which makes for easy deployment. Main issue is the font handling seems very convoluted to get started with.

Another thing I've been mulling is the idea of making my own toolkit, very much like KSSM here (although probably in Go).

These are some interesting links.
To be honest, I have no idea how to deal to make them work together with FBInk... That is way beyond my skills 😉
What stopped you from making your own toolkit? If you had already thought about it, what major changes would you do?

[sherman]

Originally Posted by Mavireck

These are some interesting links.
To be honest, I have no idea how to deal to make them work together with FBInk... That is way beyond my skills 😉
What stopped you from making your own toolkit? If you had already thought about it, what major changes would you do?

Still trying to work out in my head how it would all work, especially event handling. And what language I'd use, because while Go is nice, C is definitely more universal and one could make language bindings after the fact.

And of course, once my brain started to think about toolkits, it wanted to go the whole hog with layouts and widgets and event handling...

[lohtse]

Originally Posted by Mavireck

Some general news:

I recently worked on a framework to write apps more easily.
It is not revolutionnary, (every big app like Plato and Koreader include a similar framework). It is integrated inside tools like tkinter etc, but here I decided to work on a simple implementation to write simple code.

You can find it here :
KSSM - KoboScreenStackManager

What it does
When you build an app, at some point you need to write to the framebuffer. NiLuJe's FBInk is a librairy that does that for you, and it expects as arguments raw image files.
So what KSSM does, is that it handles the printing and removal of the images. So it keeps in memory which images have already been printed.
For instance, you can update something which is hidden by a popup very easily!

(And at some point it will come with prebuilt objects like popups, prompts, keyboard, buttons, lists, etc...)

Just... why??
Because when I developped my dashboard, I eventually found myself to be needing a more standardized way to print things on the screen, and to update modules which were sometimes hidden by the keyboard.
So I worked on KSSM.
And my life is becoming easier
(altough to this day, I have not yet ported my dashboard to KSSM entirely)

Good to hear about this...Hoping for more utils for our Kobos as a result... Thank you for all your work..

Looking forward to the next dashboard release.

[Mavireck]

AN UPDATE
I got my hands on a KoboMini yesterday.
Although I realized some fonts files were corrupted (??), therefore crashing the app, it worked well on the mini out of the box, except for a few missized icons (oh and touch input is not working too - I will need to figure out how to fix KIP for non H2O devices)

https://github.com/Mavireck/Kobo-Das...eases/tag/v1.6
Have fun!

And as I said earlier, September has started, so I will be absent for about 10 months. (You may therefore consider this project to be discontinued)

A quick note about KSSM (which has become PSSM instead)
The dashboard is not based on PSSM yet. I have made a PSSM version of my Python Launcher, but I was ahaving some trouble with my tag system, which I will remove. I will instead use a nested tree-like structure for the stack. But that is going to be for next year.

[lohtse]

where does Api key and location go???


also a shame you will have to discontinue it... Looking great so far

[Mavireck]

Originally Posted by lohtse

where does Api key and location go???


also a shame you will have to discontinue it... Looking great so far

There are located in the config file at :
.adds/mavireck/Kobo-Dashboard/files/config.json