Bounty proposal: Paint

Spot the deliberate mistake – my 16K radio button should have been a 64K one. Oops.
At some point this dialogue is going to need a checkbox for CMYK or two radio buttons to choose between CMYK and RGB as well, so I probably do need the wider layout.

The Create New Sprite dialog has always been a real mess, so any changes are improvements :)

Of the two layouts, I prefer the second – grouping the various transparency types together seems sensible. I’d suggest putting ‘no mask’ at the top of the list, though (similarly with the palette options). How about ‘Binary mask’ as a name candidate for the old-style Acorn mask?

My main suggestion, given how many blocks of radio icons there are now, is to use some frame icons to visually group them. There are basically four groups to cover (colours, dpi, palette, and transparency settings), so putting each of these inside a labelled frame would certainly make the dialog easier on the eye. That would probably mean making the window a bit bigger, but that should be OK, as it’s not a huge window to start with.

making the window a bit bigger, but that should be OK, as it’s not a huge window to start with

Well it does already fill about 2/3 of the screen at 640 × 480 with my new layouts :(

Well it does already fill about 2/3 of the screen at 640 × 480 with my new layouts :(

Wow – really? I guess it’s bigger than I thought!

Yeah, I prefer the second layout as well.

Apart from Chris’s suggestion to add frames to the radio groups, I’m wondering whether it would be possible to change them to use dropdown menus instead. But the limitation that alpha channels are only possible with some colour depths means that it might just end up being confusing for the user (with radio buttons, you can make the limitation clear by greying out the invalid options when you change the colour depth/alpha settings. With menus you’d only notice something is restricted once you open the menu.)

But the limitation that alpha channels are only possible with some colour depths means that it might just end up being confusing for the user (with radio buttons, you can make the limitation clear by greying out the invalid options when you change the colour depth/alpha settings. With menus you’d only notice something is restricted once you open the menu.)

Yeah, I thought that too. If they choose to have a palette, alpha channels will need to grey out then as well, so I think it helps for the user to instantly see the restrictions changing.

I want to go with the radio buttons at least at this stage. It will help me get something up and running quicker. I’ll work with the second layout. I think I prefer it too.

Any further votes on “Transparency mask” vs “Binary mask” vs “1bpp mask”?

Any further votes on “Transparency mask” vs “Binary mask” vs “1bpp mask”?

I’m not sure “Binary mask” would be understood by newbies, and “1bpp mask” is perhaps too jargonified?

I would be inclined to call it “Simple transparency” (a la GIF), but if it should be one of the above options, then “Transparency mask”.

Something I would also be interested in knowing is if it could be possible to create 256 colour sprites using a full palette? It seems that Paint is capable of editing these, but is incapable of creating them (the palette for 256 colour paletted sprites is the traditional 4 shades of 64 style, which cannot be edited).
You know, just in case you have some spare space in that enormous window. ;-)

Update: I’ve put an example here (if the WiFi holds out): http://heyrick.ddns.net/files/256cols.zip It is a MODE 28 sprite with a full 256 colour palette.

Something I would also be interested in knowing is if it could be possible to create 256 colour sprites using a full palette? It seems that Paint is capable of editing these, but is incapable of creating them

I’ve not looked into this bit yet, but it seems to me the bounty requirement “Able to add fully editable 256-colour palette to sprites” covers this. If an editable 256 colour palette can be added, then it can be added to a brand new 256 colour sprite.

I’m not sure “Binary mask” would be understood by newbies, and “1bpp mask” is perhaps too jargonified?

I would be inclined to call it “Simple transparency” (a la GIF), but if it should be one of the above options, then “Transparency mask”.

“Simple mask”? :)

“Simple mask”? :)

Works for me :)

Something I would also be interested in knowing is if it could be possible to create 256 colour sprites using a full palette?

I believe the workaround for that is to ask it to create a 256 colour sprite with a greyscale palette.

I hope there is built in use of !Help/BubbleHlp – windows/menus.

Are you planning on using any of the colour modules that !NetSurf uses?

I noticed that !NetSurf colours in 4000 colour mode didn’t come out correct – does one of the modules need updating?

Using ‘Use OS’ seems to work ok.

I hope there is built in use of !Help/BubbleHlp – windows/menus.

Yes it will work with !Help.

Are you planning on using any of the colour modules that !NetSurf uses?

I wasn’t planning on it. I don’t want to introduce any more dependencies than I have to (though obviously code duplication is to be avoided where possible too).

I have to confess that I have never used ‘create sprite’ in !Paint. I have done a screen shot and edited that as it is quicker. I think it needs to offer a choice between new format (3.5), new format (5.x) and old format where this would otherwise be ambiguous. I think ‘mask’ is sufficient to mean 1bpp mask and alpha to mean alpha (but I’m not sure I appreciate the difference between alpha channel and transparency anyway). Hope this helps.

between new format (3.5), new format (5.x) and old format where this would

How about new 3.5 format, new 5.x format, legacy format

How about 3.5, 5.25 and 8 formats?

How about 3.5, 5.25 and 8 formats?

Ha ha that’s the best idea! Good one! :D

Controversial question: should ‘legacy’ sprites be supported in terms of being saved?

RISC OS 3.5 was introduced in 1994ish – ie. 22 years ago and Win 95 was only just being prepped…

Why not on loading a numbered mode sprite convert it into 3.5 format, and then all creation, editing and saving occurs only on 3.5 and 5.x sprites?

The only purpose for full support of numbered modes now is to play with things on legacy (ie. antique!) hardware; in which case one can use a legacy version of Paint on said legacy OS.

Controversial question: should ‘legacy’ sprites be supported in terms of being saved?

When writing software my general take on this sort of thing is to keep things backwards compatible where possible whilst still supporting new features. For Paint this would mean that if a particular sprite is only using features (colours, resolution, mask format etc) that have existed in all versions of RISC OS, it makes sense to save it in the traditional format. However, if a new feature, for example an 8 bit alpha channel, is selected, the newer format header will have to be used.

I personally can’t see much point in intentionally creating media that won’t work on old machines when there aren’t any new features in use. RISC OS has a somewhat small user base as it is and there are plenty of enthusiasts still using the older machines and OSes (myself included).

I don’t think it’s just me, as backwards compatibility seems to be an important theme in RISC OS.

More to the point, if the new Paint stopped you saving sprites in the older format, they might not work if you tried to load them in older software.

I personally can’t see much point in intentionally creating media that won’t work on old machines when there aren’t any new features in use. RISC OS has a somewhat small user base as it is and there are plenty of enthusiasts still using the older machines and OSes (myself included).

That said, it would seem sensible for the default save to be the newest format

For what it’s worth, the Style Guide still suggests supporting 3.1 when possible when making apps. You therefore need to supply a 3.1-compatible version of the app icon, which in turn would require a version of Paint that can still save old sprites.

The primary reason why not is that it complicates the GUI (if you’re making a bitmap, you just want to know ‘how big’ and ‘how many colours’ as a user; the OS should handle all the other stuff for you). If you looked at Paint with fresh eyes, being asked if you want to specify a ‘mode number’ with that, or whether you want to support ‘oldest format’. ‘old format’ or ‘new format’ simply puts a barrier in the way of using the software that wasn’t intended in the original OS philosophy (simple enough to be used in secondary education?) We are talking supporting design features that were introduced 30 years ago when the 1.44MB floppy disc was a spacious extravagance here, and the option would be nonsensical to a relatively new user to the platform.

There is a perfectly good tool to continue to develop legacy features: “Paint” for one.

For Paint this would mean that if a particular sprite is only using features (colours, resolution, mask format etc) that have existed in all versions of RISC OS, it makes sense to save it in the traditional format. However, if a new feature, for example an 8 bit alpha channel, is selected, the newer format header will have to be used.

That seems like the right approach to me, and consistent with the way Paint currently handles old and ‘new’ (3.5) format sprites.

If you looked at Paint with fresh eyes, being asked if you want to specify a ‘mode number’ with that, or whether you want to support ‘oldest format’. ‘old format’ or ‘new format’ simply puts a barrier in the way of using the software

I agree, so I think Andy’s proposed logic makes sense – don’t ask the user to specify a sprite format, just make the choice based on the colours, resolution, mask, etc. asked for. I personally wouldn’t mind the Mode Number disappearing from the GUI altogether, but equally it’s not doing much harm there. It’s worth remembering that Jeffrey (I think) added a very helpful compatibility dialog, which can be used by more knowledgeable users to check exactly what format is being used.

Controversial question: should ‘legacy’ sprites be supported in terms of being saved? […] Why not on loading a numbered mode sprite convert it into 3.5 format, and then all creation, editing and saving occurs only on 3.5 and 5.x sprites?

Because for the lower quality of sprites, there seems to be no compelling reason to omit them, other than “they’re old”. Lest I remind you what !Sprites and !Sprites22 of any application consist of.

That said, it would seem sensible for the default save to be the newest format

Fair enough, so long as there is a way to override this. One of the things that I actually like about Paint is the messiness of the “New sprite” window. Why? Because I get to choose exactly what I want, without the program making assumptions for me. I can tell Paint I want this size sprite in this MODE (or this many colours) and know exactly what the result will be.
This is important, as I can make a MODE 28 sprite and then use it directly in MODE 28 with OS_SpriteOp calls, no farting around with ColourTrans or making translation tables etc etc.

If you looked at Paint with fresh eyes, being asked if you want to specify a ‘mode number’ with that, or whether you want to support ‘oldest format’. ‘old format’ or ‘new format’ simply puts a barrier in the way of using the software

Perhaps the simplest way to handle both situations is to have two New sprite dialogues. One can be very simple (size, colours) and the other can contain all the technical options. An “Advanced” or “Simple” button (as appropriate) would switch between them. Now when the Advanced dialogue “OK” button is clicked, the sprite requested will be created. Conversely, when the Simple dialogue “OK” button is clicked, Paint is free to make assumptions and create what it thinks is the most suitable type of sprite.

I suggest two dialogue windows instead of greying stuff out for three reasons: Firstly, the Simple can be kept simple instead of cluttering it with greyed out stuff. Secondly, from the point of view of a programmer it must surely be simpler to copy a few fields (size/colours) instead of greying/ungreying numerous icons. Finally, from the point of view of a user and a programmer, it is extremely clear when the program is intended to make assumptions (Simple) and when it is not (Advanced).
It’s a little bit of extra work to implement, but I think this should suit people critical of either approach. Oh, and let “Simple” be the default. Even though Acorn machines haven’t seen use “in education” since the mid-Jurassic, it is likely to be friendlier to newbies who want to try doodling stuff, to not be hit with a huge load of complicated choices. People who want the options? It can be just a click away…