Anyone able to draw a few printer icons?

Hi,
As part of the recent disc image improvements it now features an (almost complete ¹) set of application sprites for the 5 actively supported visual themes, those being

• Morris4 – the RISC OS 3 look
• Ursula – Acorn’s ill fated OS that’s similar but slightly different to RISC OS 4
• Iyonix – sprites in more colours and pixels than the human eye can perceive
• Sovereign – similar to Iyonix, but no blue jellybeans
• Raspberry – as used on the Raspberry Pi, similar to Iyonix but with the ‘Steel’ window borders

However, it looks like Ursula got the axe before all of the sprites got finished. Specifically the sprites missing are

• !Printers.dp.Resources.!Sprites named ‘ix’ and ‘dp’ for colour/B&W dot matrix
• !Printers.lj.Resources.!Sprites named ‘lj’ for laserjet
• !Printers.ps.Resources.!Sprites named ‘ps’ for postscript

They have derivatives (‘s_’ prefix and ‘su_’ prefix) so in theory that’s 12 icons in total, but in practice the prefixed ones are just greyscaled and/or with a warning triangle on top (which exists in the main Wimp set anyway) so don’t really need designing as such.

Any volunteers to design them? Timeframe is within the next week, such that the disc image can be frozen.

The design criteria are

• Should match the Ursula look, using the !Printers main icon as a guide. Since these printer model specific sprites will sit along side eachother they shouldn’t look out of place (eg. oriented at a different angle)
• Be designed in mode 28 with a default palette (a mode 15 set can be mechanically made with ChangeFSI, or designed by hand if different)
• You’re happy that these will be integrated into the ‘castle’ section of the source tree and therefore be part of the RISC OS owner’s IP.

1 = A few of the things in Diversions have been left alone due to time constraints since they don’t clash too badly with any of the themes. Also, the disc versions of the ‘Steel’ window tools are missing at present.

I could take a look at this. I’ll try to get something done in the next couple of days.

Talking of Diversions, I’m assuming it’s too late to get !Patience reviewed and submitted in time for the next OS release? I only mention it because I’ve given it some new sprites to replace the 16-colour ones it currently has.

I could take a look at this. I’ll try to get something done in the next couple of days.

That’d be great, thanks! The existing !Printers icon is in the Wimp resources if you need it for reference.

Talking of Diversions, I’m assuming it’s too late to get !Patience reviewed and submitted in time for the next OS release? I only mention it because I’ve given it some new sprites to replace the 16-colour ones it currently has.

If it’s sprites-only changes that’s probably OK, but if there are code changes it’s probably missed the boat.

If it’s sprites-only changes that’s probably OK, but if there are code changes it’s probably missed the boat.

Would you like to include !Cat (0.18) and !CountDown (0.09) in the next release? You already have permission and the latest versions are stable and have been on !Store and/or !PackMan for some time.

Would you like to include !Cat (0.18) and !CountDown (0.09) in the next release?

I should clarify that this isn’t freezing a Raspberry Pi/Nut Pi update, that’s different and has a whole load of extra apps piled on top. This is for the disc image generated from the repository for sources held by ROOL.

Not sure when ROOL will next be up issuing the SD card images, probably best to ask them (modulo hundreds of email backlog).

Timeframe is within the next week, such that the disc image can be frozen.

Now I’m puzzled. As far as I understand it, the disc image has changed whenever something changed and there is no even-numbered/odd-numbered attribute to reflect a frozen/tested status.

When it is frozen (for whatever reason) then I can produce an “update from Iyonix 5.16” version that will delete stuff no longer present and add/amend stuff that has changed. I can even add a ‘conditional add’ where the latest version of a module is not provided and a later one exists and a ‘backup’ of removed and altered files if you like?

First attempt here. Are these on the right lines? If so, can tidy up and produce greyed-out versions, etc.

The RO5 !Printers default is an inkjet(?) printer icon in the same style as the other printer types. Would it be a good idea to redefine the main Ursula !Printers to be in line with that, rather than the current off-centre dot-matrix icon with a ream of paper?

First attempt here. Are these on the right lines?

Looking good.
My only comments would be that I’d probably make ‘ix’ be the same shape body as ‘dp’, simply because a colour dot matrix would be at least as big as a black and white one, rather than smaller.

You may need to add a status LED or something to ‘lj’ and ‘ps’ so that when greyed-out they’re a bit more distinct. Not sure why Ursula didn’t have the yellow tint (that RISC OS 3 & 5 use) so that greyed-out was a bit more obvious.

Would it be a good idea to redefine the main Ursula !Printers to be in line with that, rather than the current off-centre dot-matrix icon with a ream of paper?

I proposed leaving the main !Printers icon alone, simply because it resides alongside FontPrint and PrintEdit in the same directory. So reworking one would need another 3 sets which was more effort than I felt worth.

OK, new set here.

The greyed-out icons hopefully look a little different, although there’s not much room for manoeuvre.

The greyed-out icons hopefully look a little different, although there’s not much room for manoeuvre.

Yes, I think the effect is good (I have lj and ps setup normally) when deselected given the greys you have to play with. I bow to your pixel lining up skills.

Looking at the !printers/s!printers/su!printers icons in the Wimp pool the latter two also remove the paper from the paper tray, though I think that’s trying to say “no printer is configured” rather than “the printer is offline”.

Are these from vector masters? Or should I just grind them down for EX1 EY2 modes with ChangeFSI?

Now I’m puzzled. As far as I understand it, the disc image has changed whenever something changed and there is no even-numbered/odd-numbered attribute to reflect a frozen/tested status.

This could be heralding a brave new era where there is a stable disc image (maybe even available on a CD for backup purposes) to go with a stable OS ROM.

Looking at the printers/su!printers icons in the Wimp pool the latter two also remove the paper from the paper tray.

Ah, you’re right. It would be easy to change this set to match, but TBH I’m not sure it adds a lot.

Are these from vector masters? Or should I just grind them down for EX1 EY2 modes with ChangeFSI?

No, they’re just knocked together in Paint. If you’re happy to produce low-res versions in ChageFSI, that would be great.

This could be heralding a brave new era where there is a stable disc image (maybe even available on a CD for backup purposes) to go with a stable OS ROM.

That would be a very good development. The next thing is to do a ‘update’ utility that will take a (say) Iyonix 5.16 standard disc image [with all the bits the user has added] and upgrade it to the latest disc image intelligently.

The candidates for such an upgrade would be RC8 on the Pi, RComp’s latest PandaLand image, RComp’s latest ARMini image and 5.16 and 5.18 on the Iyonix. I think I have all the info I need to produce such an update utility (apart from the finished disc image).

It would be easy to change this set to match, but TBH I’m not sure it adds a lot.

Agreed, your designs already convey the meaning so let’s run with that. I’ll grind them down to EX1 EY2 in ChangeFSI. Thanks for your help on this.

This could be heralding a brave new era where there is a stable disc image (maybe even available on a CD for backup purposes) to go with a stable OS ROM.

That would be a very good development. The next thing is to do a ‘update’ utility that will upgrade [existing] to the latest disc image intelligently.

I’d imagine for RC8 on the Pi that PackMan will be used to do this, but no idea for Panda/ARMini/Iyonix. The upgrade procedure should be pretty simple, along the lines of

1. Find each application in turn, delete the old one, install the new one. All the apps are now polite and only store their choices in the proper place (part of the work for booting off read only media) so none of them modify themselves (any more).
2. For !Boot, move the old one out of the way and install the new one. Don’t try to merge them.
3. Install the ROM
4. Reboot (which copies the relevant hook directory in for the new OS)
5. Pick over the bones of Boot/Resources, Boot/Choices extremely carefully

The hook directories for 5.1x and 5.2x are forwards and backwards compatible so the install ROM step could be done later, but the 5.1x has some dead wood in it that’s no longer needed, hence where I placed it.

Somewhere there’s a magic script that compares CVS trees, normally it’s used to compare two different ROM releases in order to make the release notes. I’ve not looked but it can probably compare by date which would at least get a change list of “something from the 5.18 era” to “today” reasonably easily.

I’d imagine for RC8 on the Pi that PackMan will be used to do this, but no idea for Panda/ARMini/Iyonix.

What’s wrong with adding the Packman setup to the Panda etc builds? Admittedly some people might sulk if they had something useful forced on them…