BannerLoad free tool from RISC OS Developments

Whilst doing some work for the web browsers, I have put together a standalone executable for showing a splash banner to hide long load times.

BannerLoad will open a window showing a banner (sized to your sprite), then filer_run a specified file. It will multi-task for 1 second, or until the other program relinquishes control to the wimp. An hourglass is displayed during this time.

Syntax is (for example) <OWB$Dir>.BannerLoad [filename]

Typically [filename] will be a an Obey file with something like a WimpSlot command and the call to the main executable.

The result is that a banner will be displayed to indicate activity whilst the application loads its shared libraries (etc). It will then disappear cleanly upon completion. Users can also press space or click mouse to skip banner, provided that control has been returned (eg. for fast loading code).

Bannerload is available free of charge on request from andrew at riscosdev com address, or any of my other email addresses.

showing a splash banner to hide long load times.

Hmm, I wrote one ages ago. Showed sprites or DrawFiles, supported transparency… I ought to see if I can dig it up.

I stopped using it because, generally speaking, if something needs to take time to start up, it’s better for the application itself to show a simple window with an indication of what it is doing, and some sort of representation of how far along the process it is. I don’t care about the pretty graphics, I want to know when it’ll be ready. But then I’m an impatient sod with the attention span of a dead gnat…

Well, there’s also the minor problem of chicken/egg. The program can’t show progress when it is the program that is the source of the delay!

I suppose it’d be quite nice if the shared library manager could give some idea of percentage complete in terms of loading shared libs, but often one will be dramatically slower/larger than the others.

f something needs to take time to start up, it’s better for the application itself to show a simple window with an indication of what it is doing,

I recall a situation with Windows file transfer and that swirly paper graphic.
With the graphic a file transfer could take minutes, using the underlying file transfer routines from a script did the same job in a few seconds. That’s one of the aspects of Windows GUI I deride and the reason many of my colleagues dont use the standard GUI for large transfers.

I suppose it’d be quite nice if the shared library manager could give some idea of percentage complete in terms of loading shared libs

Ooh, I wonder if we could have RISC OS minutes to match Microsoft minutes?

@ Steve Pampling I bet you could get more done/in a RISC OS minute, than a $!%@&^(*& one. Ducks fast.

From https://xkcd.com/612/

I recall a situation with Windows file transfer and that swirly paper graphic.
With the graphic a file transfer could take minutes, using the underlying file transfer routines from a script did the same job in a few seconds. That’s one of the aspects of Windows GUI I deride and the reason many of my colleagues dont use the standard GUI for large transfers.

another reason to use command line instead of gui: “xcopy /d” will do what RISC OS does with “newer” set.

RiscOsRealityCheck:

• Splash screens do not slow down initialisation
• A GUI does not make things slower
• Something done badly is worse than something done less badly
• Microsoft is capable of inventing extraordinary ways of doing things badly¹

¹ Having worked with them, I am in permanent awe of their sheer inventive genius for pushing the envelope of what can be described as “extraordinarily stupid”

Having worked with them, I am in permanent awe of their sheer inventive genius for pushing the envelope of what can be described as “extraordinarily stupid”

http://clive.semmens.org.uk/024_ROUGOL/PP.html

That was a project of a Migrainesoft Fellow…

Technically the splash screen does make things very slightly slower because you have to factor in the load time for the banner graphic, and the time required to open and display the window (negligable). The best advise I can give is to keep banners small and neat, with sizes in the low kilobytes not megabytes. Lowering the colour depth can help, depending on the artwork, as you can often dramatically reduce file sizes without significantly lowering perceived quality.

Note this is on machines with slow storage, which is why this is needed in the first place. As you’ll read elsewhere, we need to tackle the amount of time shared libraries take to load/initialise, as it is all rather uncomfortable when dealing with large, complex applications with many dependencies.

Strangely, I am often told that programs with splash screens seem to load faster, because the user sees something happen, and their mind is distracted by the pretty picture. 20 seconds of “oh, isn’t that pretty” vs 20 seconds of “oh golly, is anything actually happening… PANIC!”.

Clive reminisced

That was a project of

I. want. that. keyboard.

Andrew pedanted

does make things very slightly slower

If ones application is slow to boot it is not because of the splash screen.

programs with splash screens seem to load faster

This is an important effect and most noticeably applies to redraw – the typical RISC OS Painter’s Algorithm approach can seem more responsive than the render-to-buffer-then-blit approach that is common elsewhere, even if it takes longer. At least it’s visibly busy.

I. want. that. keyboard.

It’s yours if you really want it, if we can work out how to get it to you. I think Crispin’s driver for it only works on Windows 2000 and it has a PS2 connection; whether it still works at all I’ve no idea. It’s in my Playroom – http://clive.semmens.org.uk/DIY/Playroom.html – which is dry, so there’s a chance it’s still functional. Or of course for a museum of Daft Objects, functionality ain’t important.

RiscOsRealityCheck:

The OS is written in such a way as to maximise the interactive user experience, security isn’t a factor.
With Windows instances of the same era it wasn’t a factor either – things move on.

Splash screens do not slow down initialisation

Properly written splash screens don’t

A GUI does not make things slower

A well written GUI may make things marginally slower, but the user won’t really notice because the margin is small.

Something done badly is worse than something done less badly

Or not at all – see security.

Microsoft is capable of inventing extraordinary ways of doing things badly

There is a small percentage of the world that disagrees with that statement (see small margins)

I am in permanent awe of their sheer inventive genius for pushing the envelope of what can be described as “extraordinarily stupid”

Which is where my comments about the “swirly paper” and similar come into play.
If the transfer was faster the graphic effect wouldn’t be considered as even vaguely necessary, and the reason the transfer is slow is the graphic entertainment put in place to keep you occupied while the slow transfer occurs. As you say: “extraordinarily stupid”
Maybe someone could knock some sense into these people, would a baseball bat do the job or would a lump hammer be more appropriate?

I shall cease, this is Announcements after all.

I. want. that. keyboard.

:-)

I like the idea of quickly accessible keys for bold and italics and such. Couple with keypresses to set up predefined styles, it could be useful for DTP.

I’m not so keen on all the accented keys. Isn’t that a solved problem using modifiers? Okay, British International under Windows and the RISC OS methods differ (and sodding Android doesn’t do it at all using a UK layout Bluetooth keyboard – boo!) but the ability is there.

I guess these days the extra keys are all about calling up a search engine and controlling music playback. RISC OS doesn’t support those multimedia keys (yet?) but it would be nice if it does to be able to use the extended key codes for application defined reasons (like the F keys).

I like the idea of quickly accessible keys for bold and italics and such.

I’m quite happy with ctrl-i and ctrl-b for italic and bold, and so forth. A QWERTY keyboard plus a handful of keys like ctrl, alt, shift really is all you need. A huge array of extra keys like that just makes touch typing impossible.

Before computers, typewriters had accents that didn’t advance the carriage so you typed the accent and then the letter it belonged to. That’s a really easy way to enter the text – alt- (or whatever) some character or other for each accent, followed by the character the accent belongs to – easy to remember, easy to touchtype. And suitable keyboard driver software can easily generate the corresponding Unicode.

– alt- […] some character or other for each accent, followed by the character the accent belongs to

I assume you wrote that in the knowledge that RISC OS does it, but maybe not everyone does. The information is only documented in the Welcome Guide as far as I know.

The information is only documented in the Welcome Guide as far as I know.

And here

Thanks. It is excellent, but in the Wiki, so missed by me. ;-(

I’m not so keen on all the accented keys

Keytops are replaceable!

I’m excited about having lots of hot keys that can be bound to programs. As could be done on the MMK (but it only had four)

I’m excited about having lots of hot keys that can be bound to programs.

Fair enough. I prefer key combinations to having lots of keys; I can touchtype combinations, have to hunt and peck with a keyboard much bigger than a standard QWERTY. (A little bigger is fine – three or four extra alt/shift/ctrl type keys for example.)

I assume you wrote that in the knowledge that RISC OS does it

I’d forgotten whether RISCOS did it natively or not; we used it heavily in preparing academic journals, but I wrote a lot of the software we used (in combination mostly with !Draw and !mpression Publisher) including the keyboard drivers. (I’d still write my own keyboard drivers if I could, but I used !IKHG which afaik hasn’t been updated for post-RiscPC hardware.)

Syntax is (for example) <OWB$Dir>.BannerLoad [filename]

How about:
Syntax is (for example) <OWB$Dir>.BannerLoad [filename] [<time>]
time in seconds defaulting to 1.

Oh and support for jpegs, draw files… I’m good at feature creep!

I did consider a time parameter, Chris, yes. But then I thought about it and if your program is so quick to load that you need to alter the time (ie. <2 sec) then really the sooner the banner disappears, the sooner users will notice the program is ready for use. 1sec actually feels much longer in use (probably more like 1.5-2s) based on my tests.

Since I’ve actually modified it to pass whole command lines on (no more Filer_Run) syntax would probably need to be [] [] but is it worth it? Not really sure. If anyone needs that, I’ll add it, or they can (source is included).

I changed the [filname] to [] so that (for example) additional parameters could be passed to the executable (eg. URLs) as that will be essential for the browsers. That required a few internal changes due to differences in behaviour between Filer_Run (which cannot take parameters AFAIK, but was used previously) behaves a little differently to other ways of launching executables. Anyway, it all seems to work.