LiveCode Forums.

It has long annoyed me that the spinner widget doesn’t actually spin when you need it to - during lockScreen or when a database fetch blocks everything. Animated gifs are no better.

Inspired by some comment in some other thread here, about the browser widget, I embarked on building myself a tool for crafting spinners animated in browser widgets, as those would continue spinning in a heavenly layer of its own, no matter what traffic jams occur down on LC ground level…

Of course the project grew bigger than initially planned, as they do, and is not finished yet, as they never are - but at least I have something good enough to use, and good enough to share (I think).

The stack is designed for use it in the LC IDE, to craft the spinner (or whatever animation you want) and then copy the browser widget (or just the htmlText) to wherever you want to use it. The code is completely self-sufficient (html and css all crammed in).
One can obviously make any kind of repeating animation with it (within the limits of the current css animation lib), not only spinners.

Here is a link to the gitHub rep:
https://github.com/wheninspace/WIS_BrowserAnimation

And here is a web deployment of it (LC10 dp5), just to prove that the resulting code also works on web.
https://wheninspace.com/browseranimation/
(Make sure to click the "Show examples” button to see some cool examples… )

Please let me know if you find it useful (or how to improve it, if it isn't).

Hi Andreas,

https://wheninspace.com/browseranimation/

That is a wonderful webApp and thank you for the downloadable code.

It does indeed overcome the limitation that when doing some long processing a progress indicator does not work. Very nice.

Kind regards
Bernd

Good work, Andreas.

Multiprocessing is a good option in the absence of threaded GIF animation, but non-obvious for new users and more resource intensive.

For the long term LC will needs to run animated GIFs in a separate thread to be competitive with modern tools.

https://quality.livecode.com/show_bug.cgi?id=7600

It is 'funny' that multithreading has, apparently, not been developed by LC; and, as a consequence end-users have
had to develop a whole slew of work arounds.

Other languages like XOJO have tried to address this by facilitating creation of helper apps that support the main app, since each app would effectively be a thread. Not convinced they actually cracked that nut, but the idea still appeals.

I wonder if you could palm off the computing intensive task to such a faceless helper app (perhaps communicating with main app via sockets or some such) leaving the main app free to do the pretty animations?

Ideally this would be something facilitated by the IDE and language, but their focus is necessarily elsewhere nowadays I think…

S.

I would not advocate exposing threading through a scripting interface. Python and most others are single-threaded for a reason.

But internally the engine could use a thread for that one task, animating a GIF, and doing so would decouple the playback from other script execution.

We see most progress indicators are asynchronous, not stuttering because the scripter had to manually interleave playback updates with the process whose progress is being indicated by that playback.

I'm no expert in C++ threading, but we see smoothly asynchronous progress indicators so commonly it's hard to imagine it's a prohibitively exotic technology.

I was fooling around with a spinner in a substack this afternoon . . .

Does lockScreen lock the whole computer's screen refresh 'thing', just that of the stack (with/without any substacks) where it is invoked?

Why do I think 'aloud' hereabouts?

Why do I have a feeling about WAIT?

Annoyingly:
- - The lockScreen message [if the instructions are in this order] does NOT come into play
until the openCard script in the substack has executed.

AND it appears that without waiting ONLY applies to object movement.

Thanks guys for testing it and for the kind comments.

I have now updated the tool with the possibility to set the duration of the animations. This is quite good, as many of the animation effects are rather frantic, but with this new ability to slow them down they become more useful in my opinion.

Also, combining two animation effects becomes more interesting now when you can balance their durations independently, making for more varied movements.

And even better, I have also added… *drumroll* … more fish!
Eh, in the examples sections that is. It really is worth another visit to the web deployment just to see the fish, I promise! And the crab (proving that the animations continue during the move command too…

This is absolutely great!!! thanks.

Unfortunately I tested it in an Android 13 hardware Phone and the spinner is rather scatty.
On iOS hardware and Mac works beautifully.
Any idea in this regard?

Trevix

Thanks, Trevix!

Unfortunately, I don't have any Android devices to test with. It seems a bit strange that it would not work well in Android browsers, considering that it is basically just html/css code.
If you go to the page where the animations are provided, https://loading.io/animation/, how do those appear?
If they look fine, then I suppose it's maybe the LC browser widget that performs worse on Android...?

If you go to the page where the animations are provided, https://loading.io/animation/, how do those appear?

They look fine.
Somebody else can confirm that, on Android hardware, the copied widget browser does not performs well with the Andy spinner?

I have one question. if I can:

In my standalone, particularly on Android, unfortunately I nee to put quite a number of spinners here and there, for taking care of the user logging in to server or uploading/downloading stuff from a remote DB and other operations.
When the browser widget is hidden, for what you know, does its HTML code keep running anyway, using cycles of the device processor or it stop quietly there, waiting to be shown again? Is it something to be concerned?

Thanks
Trevix

One more question

I resized my web spinner in the IDE and pasted in my standalone.
Running the standalone on iOS, simulator and hardware, the spinner is much more smaller then what appears on the IDE. Like 4-5 time smaller.
On Android the size of the spinner in the standalone is fine.

What could be the problem and is there a solution?
Thanks again.

Trevix

trevix wrote: ↑

Sun May 07, 2023 11:11 am

In my standalone, particularly on Android, unfortunately I nee to put quite a number of spinners here and there, for taking care of the user logging in to server or uploading/downloading stuff from a remote DB and other operations.
When the browser widget is hidden, for what you know, does its HTML code keep running anyway, using cycles of the device processor or it stop quietly there, waiting to be shown again? Is it something to be concerned?

That's an interesting question, and I don't know the answer. When I've been testing this technology, I've sometimes seen problems with (re)loading the browser content when moving from one card to another. So I've been thinking of recommending as a good practice to actually always reload the htmlText of the browser every time it is shown (or when moving to a card that has a visible browser). This would then also take care of the potential processor strain of a hidden browser.

In practice, this would be my method:

Once, in the IDE, save the htmlCode of the browser in a custom prop, in the stack or in the browser control itself: Then, in the scripts that show and hide the browser:
and
You could even go a step further if you prefer and create/delete the browser control on the fly, so that it only exists when needed.