BannerLoad free tool from RISC OS Developments
Andrew Rawnsley (492) 1443 posts |
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. |
Rick Murray (539) 13806 posts |
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… |
Andrew Rawnsley (492) 1443 posts |
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. |
Steve Pampling (1551) 8155 posts |
I recall a situation with Windows file transfer and that swirly paper graphic.
Ooh, I wonder if we could have RISC OS minutes to match Microsoft minutes? |
Ian Cook (420) 11 posts |
@ Steve Pampling I bet you could get more done/in a RISC OS minute, than a $!%@&^(*& one. Ducks fast. |
Jeff Doggett (257) 234 posts | |
Alan Adams (2486) 1147 posts |
another reason to use command line instead of gui: “xcopy /d” will do what RISC OS does with “newer” set. |
nemo (145) 2529 posts |
RiscOsRealityCheck: • Splash screens do not slow down initialisation 1 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” |
Clive Semmens (2335) 3276 posts |
http://clive.semmens.org.uk/024_ROUGOL/PP.html That was a project of a Migrainesoft Fellow… |
Andrew Rawnsley (492) 1443 posts |
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!”. |
nemo (145) 2529 posts |
Clive reminisced
I. want. that. keyboard. Andrew pedanted
If ones application is slow to boot it is not because of the splash screen.
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. |
Clive Semmens (2335) 3276 posts |
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. |
Steve Pampling (1551) 8155 posts |
The OS is written in such a way as to maximise the interactive user experience, security isn’t a factor.
Properly written splash screens don’t
A well written GUI may make things marginally slower, but the user won’t really notice because the margin is small.
Or not at all – see security.
There is a small percentage of the world that disagrees with that statement (see small margins)
Which is where my comments about the “swirly paper” and similar come into play. I shall cease, this is Announcements after all. |
Rick Murray (539) 13806 posts |
:-) 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). |
Clive Semmens (2335) 3276 posts |
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. |
Steve Drain (222) 1620 posts |
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. |
Stuart Painting (5389) 712 posts |
And here |
Steve Drain (222) 1620 posts |
Thanks. It is excellent, but in the Wiki, so missed by me. ;-( |
nemo (145) 2529 posts |
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) |
Clive Semmens (2335) 3276 posts |
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’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.) |
Chris Evans (457) 1614 posts |
How about: Oh and support for jpegs, draw files… I’m good at feature creep! |
Andrew Rawnsley (492) 1443 posts |
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 [ I changed the [filname] to [ |