Bounty proposal: Paint

The alternative is a “Claim focus” menu option, but that makes the behaviour a bit esoteric. :)

I very much disagree with the notion of needing to click twice in a window without the input focus before it does anything.

Another alternative is possibly to consider changing the default behaviour so that all windows claim focus when their title bars are Select-clicked (but not for Adjust). This would take some getting used to and would ideally need to be configurable so users could disable it. It’d also introduce issues when wanting to bring a window to the front without giving it focus… which could be (perhaps clumsily) worked around by Select-clicking on the adjust size icon (if it happens to be visible). Has this sort of thing been discussed before?

Here’s a version of the mockup with a “Paint tools window” opener:

It has to be things that the app draws down there, rather than bitmap icons, as the height available varies depending on the toolsprites.

More importantly, we need to consider how alpha channels can be displayed and edited. We could have an “Open mask editor” menu entry which could open a 256 greys sprite representation of the alpha channel.

Even though I’ve been using it for years, I’ve never really grown familiar with the current 256 colour palette arrangement:

Here’s a more artist-friendly arrangement of the standard palette display:

It’s all the same colours as normal, just moved to different places. The groupings are:

Grayscales (top)

• A continuous graduation of 16 greys.

Bright colours (bottom left)

• 18 continuous graduations, each of four colours.

Muted colours (bottom right)

• Six continuous graduations, each of 12 colours.
• (Perhaps reversing the middle row of each 4×3 block would be better?)

Intermediate colours (upper)

• 12 continuous graduations, each of 8 colours.

Each colour section is arranged circularly by hue, with red at top left.

One of the ideas suggested that I really like is the small fore/back colour swatches beside the scroll bar, though I wonder how cooperative the wimp would be in doing such a thing (the harder it is to implement, the less likely it will happen).

Well NetSurf manages, and it needn’t have the extra complexity of being resizeable like NetSurf’s status bar.

It’s a function of the Nested Wimp, IIRC. If the pane is placed precisely over the scrollbar, I think the Wimp embeds it for you.

You need to set window flag bit 23 of a nested window to move it in front of its parent window’s furniture (title bar, scroll bars etc) – the same bit you use for top-level windows to force them to stay at the front of the window stack; it’s roughly analogous behaviour, which is why it re-used the same flag bit. The scroll bars will shuffle themselves to one side if you fully overlap one end of them. I think you can even overlap both ends with different nested windows if you really want.

I’ve revised Trevor’s wiki page here, and formatted it as a bounty proposal. I’ve omitted any of proposals where there were significant differences of opinion, and tried to make it as simple as possible.

Note that I’ve retained the idea of Spritefile windows having an input focus/key shortcuts, but not the actual editor windows. If this is also controversial, it can be removed.

Is this worth submitting to ROOL for consideration?

I’ve updated the wiki page with a few more of the ideas, and clarified a few points.

Does anyone think rearranging the display of the default 8-bit palette would be worthwhile?

rearranging the display of the default 8-bit palette

Your proposal above provides a more logical and user-friendly arrangement IMHO.

Does anyone think rearranging the display of the default 8-bit palette would be worthwhile?

That’s what I had in mind as part of the ‘more comprehensive palette editing’ item, but no harm in making it explicit. I do think it would be a useful feature.

More ideas:

• When selecting the “Move whole sprite” tool, there should be a “Wrap” checkbox, which when enabled makes what moves out on one side appear on the other. (Would be super handy for ensuring texture tile seamlessness.)
• Text tool should have a font selection menu.

I’ve tweaked the page a bit as well (mainly adding mention of 4K colour sprites, and linking to a couple of bugs/forum threads).

A rearranged 256 colour palette sounds like a good idea to me, although it might be a bit odd when the palette jumps between the two formats (if the new view is automatically used when the default palette is detected, imagine what happens if someone edits a standard palette and then closes and re-opens the view)

One thing worth considering: RISC OS 3.5 compatibility. The disc image is 3.5 compatible, and contains a copy of !Paint for use (since 3.5 lacks a copy in ROM). So we’ll probably want to stipulate that the new paint remains RISC OS 3.5 compatible, and that the feature set that’s available on RISC OS 3.5 is no less than the set that’s currently available. E.g. because paint is so heavily dependent on the kernel/SpriteExtend, there’s no requirement to support the new sprite types. But any changes to existing tools should make sure those tools continue to work on 3.5. Making changes which require a new WindowManager should be fine, as that can easily be softloaded during the boot sequence.

A rearranged 256 colour palette sounds like a good idea to me, although it might be a bit odd when the palette jumps between the two formats (if the new view is automatically used when the default palette is detected, imagine what happens if someone edits a standard palette and then closes and re-opens the view)

If they add a palette with the new version of Paint, there’s no reason the explicit palette couldn’t be defined in the order of the new palette display, is there?

What’s the crash on brush selection? Any mode/sprite? Circumstances?

If they add a palette with the new version of Paint, there’s no reason the explicit palette couldn’t be defined in the order of the new palette display, is there?

There’s no technical reason, no. But there will be performance gains from using the standard palette where possible (not to mention the resulting sprite being Arc compatible).

What’s the crash on brush selection? Any mode/sprite? Circumstances?

I believe it’s this long-standing bug

There’s no technical reason, no. But there will be performance gains from using the standard palette where possible (not to mention the resulting sprite being Arc compatible).

Surely once you’ve added an explicit palette to the sprite, even if it’s in exactly the same order as the standard palette definition, you’ve already had the performance drop?

I’ve just realised that the alpha channel support with the brush tool effectively provides airbrush capability. Might be worth having some predefined generated brushes, like how the brush tool currently has some predefined shapes.

Surely once you’ve added an explicit palette to the sprite, even if it’s in exactly the same order as the standard palette definition, you’ve already had the performance drop?

Not really. ColourTrans caches the translation tables that are generated for plotting things in palletised modes, so it should spot that the explicitly defined default palette used by the sprite matches the implicitly defined 256 colour default palette and will reuse translation tables where appropriate.

For plotting in 256 colour modes using the default palette, if the caller didn’t spot that the palette/translation table wasn’t required then SpriteExtend has its own checks to detect and discard identity translation tables – so it should still be (just about) as fast as if there was no palette. Certainly a lot faster than if a custom palette was used (n.b. I haven’t timed this myself!)

For plotting in true colour modes there’s effectively no difference in performance as a palette lookup will always be needed.

I’ve just realised that the alpha channel support with the brush tool effectively provides airbrush capability. Might be worth having some predefined generated brushes, like how the brush tool currently has some predefined shapes.

Yes, some kind of airbrush functionality could be nice, and shouldn’t tread on the toes of commercial image editors too much. It’s also something that could be made to work on older OS versions (alpha-masked brush sprites probably wouldn’t work on older OS’s due to the kernel not understanding them, but a simple brush opacity value would work as translucent sprite rendering can be handled by SpriteExtend+BlendTable+InverseTable softloads)

So how about this:

I believe it’s this long-standing bug

I’ve added a link from the wiki page.

One feature of ROL’s Paint that I did like was:

• PNG format load/save.

I’m not entirely sure I like the idea of the artist-friendly default palette automatically staying artist-friendly after it’s been modified – that means it would have to remap the sprite pixels, which the user might not want to happen.

It would be a bit clunky, but maybe we could add a popup which asks the user whether remapping the pixels is allowed?

It only matters when modifying the palette, and if palette editing facilities are to be expanded anyway, maybe it can just be an option in the new palette editor?

I’ve updated the bounty proposal with those brush tool ideas.

Speaking of the Brush tool, I’ve always thought it was bad interface design to have to type in the sprite name to be used. Would this be possible:

   +-------------+ +-+
   |Writeable    | |M|
   +-------------+ +-+

Where that’s a writeable icon for sprite name entry, and there’s a gright menu opener icon next to it, which opens a menu listing all the available sprite names. Selecting one from the menu would set the text in the writeable icon.

The brush tool used to allow you to use any sprite in the Wimp sprite pool, and indeed that was exactly how the default ‘circle’ sprite was implemented. It was perfectly reasonable to enter something like “file_fff” in there, and I’ve done it. For some reason, though, this doesn’t seem to work in the latest version.

…Aaand Paint crashed while I was testing that. Yeah, not good.

Where that’s a writeable icon for sprite name entry, and there’s a gright menu opener icon next to it, which opens a menu listing all the available sprite names.

Possibly, but even that could be clumsy for spritefiles with lots of sprites, and even more so if the entire Wimp pool were available to use.

I wondered about having a drop box for dragging sprites from Spritefile windows.

The brush tool used to allow you to use any sprite in the Wimp sprite pool, and indeed that was exactly how the default ‘circle’ sprite was implemented.

I don’t think the shapes, like “circle” should be actual sprites, rather they should be internally generated sprites created when you select them. At the moment “circle” becomes really pixelated when you give it 4:1 scale.

I wondered about having a drop box for dragging sprites from Spritefile windows.

That might be better. I don’t feel it’s perfect either though. :)