[Idea] Activity bar

[shermp]

Quick! Hide! I have another one...

So, FBInk has a progress bar. But sometimes we have to wait for an indeterminate amount of time for a task to complete. Wouldn't it be great if we had a nice scrolling activity bar to reassure the user that, no, we haven't crashed?

The idea would be to define a fixed range of positions that the dev can set the 'scroll bar/widget' to, and that way the dev can decide on their scrolling pattern and frequency. Sure, such an idea is not going to result in smooth scrolling, but it would be effective enough.

Thoughts?

Right, I'll see myself out now. :)

[NiLuJe]

It's definitely something useful to have ;).

I went with a simple spinner in a backgrounder subshell in KOReader (https://github.com/koreader/koreader/blob/master/platform/common/spinning_zsync), but I guess something of the sort could be baked in...

It'd of course be blocking ;).

In terms of looks, does what you have in mind resemble the horizontal bar example in that script?

[NiLuJe]

Basically something resembling an infinite progress bar, or indeterminate, or striped, depending on how you want to call it, right?

Either filling and emptying in a loop, or striped (that's going to be tricky, maybe just a scrolling thumb)?

[NiLuJe]

If I understood your second paragraph properly, you were thinking of a scrolling thumb with a fixed number of possible steps (say, 10, which would put 5 somewhere around the middle of the bar), on a non-blocking call, so you can "move" the thumb on your own terms (instead of what I was mentioning earlier: relying on a fixed scrolling running in the background, that you'd have to interrupt when processing finally ends).

[shermp]

Yep, that's what I was thinking about.

[NiLuJe]

Okay, initial implementation is in ;).

Mainly because that was originally how I thought about it, I did sneak in a "loop forever" behavior...

The thumb is 10% of the width of the bar, and moves in 5% increments, so that makes 19 steps.

The function takes 20 possible values as valid: 1-19 for those steps, and 0, which will loop forever, cycling between each step every 500ms. In this truly infinite state, killing that is left to the caller, however that ends up being used (probably in a detached thread in C, or in whatever the language can do to run stuff in the bg: coroutines, backgrounding, whatever ;)). (We don't do anything fancy, so Linux should cleanly takes care of the mmap and the fd on exit without having to play catch).

[NiLuJe]

I'm open to suggestions on how to make it look prettier ;).

[shermp]

Sounds good! Look forward to testing it.

On a side note, I may have gotten a little side-tracked yesterday and somehow ended up making an onscreen keyboard (and painting it with FBInk). Oops :D

[NiLuJe]

:D

[NiLuJe]

Random braindump: I may move the "infinite loop" thingy out of the API and into the CLI client only, because that feels slightly crazy as it is... ;).

[NiLuJe]

Well, I did, and encountered the weirdest performance issue ever: keeping the endless loop inlined in main was tanking performance in a completely unrelated codepath.

o_O

TL;DR: Moved it to a function, things back to normal.

[shermp]

I know very little about these sort of things, but maybe a compiler optimization issue?

[NiLuJe]

Quite probably, given that I can't seem to reproduce it with LTO disabled ;).

[NiLuJe]

Landed in v1.7.0 ;).