Bounty proposal: Paint

Also, on the subject of colour picking, it would be nice to be able to enter RGB hexadecimal values. Often I’m trying to set a colour to match something else, which is specified in hexadecimal. I end up using SciCalc to convert from 2-digit hex to a percentage for each colour channel. Both ArtWorks and Compo have ways to enter a value in the format of a web-style #RRGGBB value.

In the RGB tab of the colour picker, a writeable icon with the #RRGGBB value could be added in the bottom right.

You can easily start painting into a sprite and get an unexpected colour.

There’s a lot to be said for showing what the current tool will do. ie just as with the brush tool, perhaps the pixel tool should show the pixel under the pointer in the colour that will be painted with Select – no additional chrome required.

That wouldn’t solve the problem of having 5 or 10 different colour pickers open, and no idea which one belongs to the sprite you want to edit. I know the sprite name is in the colour picker’s titlebar, but I don’t find that’s enough of a help. Also, it would probably be too slow for flood fill.

I very much like the idea of having a colour icon in the main sprite window.

it would be nice to be able to enter RGB hexadecimal values

Completely agree – percentages are often a pain to use when trying to match sprite colours. Although I assume Paint uses the global colour picker, and hence it would be a change to that, rather than the app itself.

Another bug, or inconsistency, is that you can set a background colour for painting with Adjust in 8bpp or fewer sprites, but there currently seems to be no way to do this in a true colour sprite.

Many worthy points here. I think Paint does need an update, not least to make it work with the new sprites, but what it doesn’t need is a revamp.

I agree with Michael about the current global tools window being best and toolbars eating up screen real estate. (Although I know attempts at nerd-baiting when I see them – I probably do it more than anyone else, so don’t think I’m going to fail to recognise even unofficial Marsquake graphics!)

That said, I like the colours-in-scrollbar idea. I often forget which colours are selected where, and the situation is exacerbated by the fact I often find myself editing multiple sprites with the same name. Also, there’s currently no indication of background colour at all!

Although I assume Paint uses the global colour picker, and hence it would be a change to that, rather than the app itself.

Maybe we could have a separate bounty for that. I wouldn’t mind using ROL’s version for reference in that case. Another vote for allowing hex colours here – in fact, why don’t we just replace the % fields with hex ones? I don’t think I’d ever miss them.

Another bug, or inconsistency, is that you can set a background colour for painting with Adjust in 8bpp or fewer sprites, but there currently seems to be no way to do this in a true colour sprite.

That can go on the colour picker list, then.

Supplement to earlier request to implement DPI/colour changes: Ability to do that without modifying the sprite data. For use when the sprite is in the wrong format for whatever reason. (This wouldn’t cause memory problems, as sprite width is internally represented as words rather than pixels, so changing the BPP would automatically change the width in pixels.) I know, I know, I’m probably the only one who’d ever use it…

so don’t think I’m going to fail to recognise even unofficial Marsquake graphics

I was actually looking for my Asylum sprite set, but could only find an early version of my Marsquake ones. :) I doubt you recognise the other two graphics. :p

Supplement to earlier request to implement DPI/colour changes

FWIW, I also agree; the ability to modify DPI would be really useful.

Ability to do that without modifying the sprite data. For use when the sprite is in the wrong format for whatever reason. (This wouldn’t cause memory problems, as sprite width is internally represented as words rather than pixels, so changing the BPP would automatically change the width in pixels.)

That would be behaviour that would seem completely broken to almost all users.

Changing bpp the way people expect is complex, it’s even usually lossy when reducing bpp, and may be better left to other apps.

[On colour pickers]

I wouldn’t mind using ROL’s version for reference in that case.

I can’t remember what they did with it.

Another vote for allowing hex colours here – in fact, why don’t we just replace the % fields with hex ones? I don’t think I’d ever miss them.

Perhaps, at least in the RGB tab. The sliders indicate the proportions already, so there’s not much point in also expressing the value as a percentage.

On !Paint:

I quite like the idea of a small toolbar across the top of a sprite window. When we talk about screen space, remember we are not, at least, blighted with the brain dead decision of plastering menus across the tops of windows, so we have a little bit of space there. Also, a fair few apps offer toolbars (look at your word processor or desktop publisher), so is this such a bad thing? I don’t think I’d like a Draw style toolbar.

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). Clicking on the colour can open the colour picker.

When I design icons and such for apps, I use Paint. Sometimes (given my drawing abilities suck) I would using Draw and InterGIF and/or ChangeFSI and then crop/correct in Paint. I have even designed icons for my VB applications in Paint. Why? Because image editors are awesome and all, but tend to be horrible horrible things for sprite/icon editing. For all of Paint’s simplicity, this is one job it does better than most other things I have tried. Sure, it is so simple it is sort of on par with Windows PaintBrush, but even so, it does a specific job well.

An undo feature, preferably (given that memory is no big deal these days) a multi-level undo; but be smart about it. You should be able to redo at least the last thing undone, and both of these facilities should be available from the keyboard.

Speaking of which, it might be nice to switch tools and/or options from the keyboard. Additionally, cursors should be able to nudge the mouse pointer so you can get perfect placement. Nothing fancy, it doesn’t need to force the image to follow the mouse of anything.

It would be great, if possible, to be able to alter the sprite type without the intermediate step of using ChangeFSI. This is primarily of use for going up like 16→256 colours, 256 colours→greyscale, or 256→16M colours. There are of course complications (converting down to 4 colours, and modes where the pixel aspect is different).

Can’t the colour picker have a radio to switch between 0-255 and 0-100? The image editor I use on the PC takes hex, and it is good for websites as the values can be matched exactly, but some of the stuff I work with uses percentages, so out comes the calculator…
[this, and the slidey bars crash is ColourPicker, not Paint……but note that Draw appears to be able to recover from such a flaw, perhaps Paint should be more bombproof in this respect?]

Bombproof… Which is to say, a timed safety autosave into !Scrap might make people a little bit happier? It is pretty damned easy to implement – Scrap$Dir.PaintSaved and then all the loaded sprite files, plus “untitled1” (etc) for unsaved ones, then (optionally) a dump of the undo cache and a small file which is a dump of various internal arrays/variables.
When Paint is closed correctly, delete all this stuff. When Paint crashes, it’ll remain.
When reloading Paint, check if the file exists. If it does, load up everything to the state it was in prior to the crash (then delete the control/array file so if the state causes another crash, reloading Paint again will not attempt to reload the previous data, to guard against repeated crashing).
It sounds a lot, but it is quite simple to implement. I’ve done this myself in a few things (mostly on the PC, but I think one of two RISC OS programs did this back circa Y2K).
You could even spin it as a “quit and save state” option to allow a user to quit Paint and come back later and have everything open back up, that’d be kind of neat.

Also, a fair few apps offer toolbars (look at your word processor or desktop publisher)

Those apps edit documents that are typically much wider than an icon. Such as A4 pages, and they put spacing around the pages as well.

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.

Clicking on the colour can open the colour picker.

Yep, that’s what I suggested. Also Adjust clicking it might be a handy way to open the tools window.

Keypresses are another issue. In the Sprite file window, it would be nice to be able to save with F3, delete with Ctrl-K, etc.

The sprite editor windows could also benefit – you could pick up colours by (say) Shift-clicking, use Ctrl to invoke a scrollwheel zoom etc., and use the standard F8 to undo. However, this would mean a change in behaviour, as you’d have to click in an editor window to gain the focus, rather than just click away as currently. So I suspect there’ll be a range of views on this one :)

In addition, a button on the toolbar for the ‘Select colour’ option on the menu would be handy too, especially if the keypress idea doesn’t find favour.

The sprite editor windows could also benefit – you could pick up colours by (say) Shift-clicking, use Ctrl to invoke a scrollwheel zoom etc., and use the standard F8 to undo. However, this would mean a change in behaviour, as you’d have to click in an editor window to gain the focus, rather than just click away as currently.

I agree with all that. Shift+Adjust click can select background colour.

Also:

F9 – Redo
Ctrl+Q – Zoom out
Ctrl+W – Zoom in

delete with Ctrl-K

Not a great fan of this – I’ve already lost files in the filer because of it. Its too easy when you have lots of windows on screen to miss that the wrong window has the input focus – another reason I change !Edit back to using ctrl-c. If I could disable key shortcuts in the filer I would.

Not a great fan of this

Of the keypress idea, or just the delete option? If the latter, would a confirm box solve the problem?

The delete option. A confirm box in paint wouldn’t help when the keypress is going to the wrong window. Confirm boxes are a waste of time for me anyway I’ve ignored them for years :-). Unfortunately the precedence has been set and Ctrl-K is being implemented more widely. For me a better option would be to implement Ctrl-X cut to clipboard. I would have liked Ctrl-K to only have been implemented with an undo option everywhere but it hasn’t so we’re stuck with it.

A “New view” option in the sprite editor menu. Often I edit a sprite at a high zoom and also want to see how it looks at 1:1. If the sprite is small enough, the Sprite file window can be used for this, but not otherwise.

A ‘New View’ menu option would be sensible, but you know you can already have multiple copies of a sprite open at different zoom levels? Just double-click on its icon in the file window.

A ‘New View’ menu option would be sensible, but you know you can already have multiple copies of a sprite open at different zoom levels? Just double-click on its icon in the file window.

Ah, yes. I’d forgotten that. :)

it would be nice to be able to enter RGB hexadecimal values

That’s a ColourPicker suggestion, not a Paint one.

DPI/colour changes: Ability to do that without modifying the sprite data

I wrote an app to do that kind of thing (import arbitrary data, set width and bpp directly, flip bytes, nibbles etc) long ago. Very useful, but not really part of Paint’s remit.

The idea of showing the Select and Adjust colours in the scrollbar is defensible, but so is ROL’s below-scrollbar info pane (zoom implementation bug aside), though it should really have its own titlebar.

However, there’s another UI elephant in the room which is exposed by the various comments in this thread – that of state surprise… you click in the window and are surprised by the result.

Part of this is due to the ancient RISC OS idiom, not shared by most other OSes, of acting immediately on a click in an editor window when it doesn’t have “the focus” (regardless of whether it responds to keypresses. This is something I considered deeply and eventually abandoned for Vantage and other programs I’ve written:

Clicking in an editor that doesn’t have the focus should give it the focus ONLY, not do anything else. At THAT point shared toolpanes (such as RO5’s shared Paint toolbox) can update to show the state for THAT editor window, floating toolbars can be attached to the active editor window and removed from inactive ones. In-window animation can show the effect of the tool (which will occur on next click) where appropriate.

All of this is, I feel, a superior user experience to the classic Arthur-era click of surprise. It also cuts down on screen clutter as you can have a single toolbox, colour palette etc, eliminating noise AND confusion.

I don’t think anyone using such a UI elsewhere would think “this would be improved by having multiple toolboxes and lots of different colour palettes/dialogs that apply to different windows in some unknown order”.

So if we’re going to touch the code, why would we preserve that disfunctional UI?

However, there’s another UI elephant in the room which is exposed by the various comments in this thread – that of state surprise… you click in the window and are surprised by the result.

I don’t see that being a problem with the current paint – you are after all in control of associating the colour window, for example, with its sprite so the state is knowable even if the process is not liked. What you do highlight is that if a window gains toolbars as a result of gaining input focus and other windows lose them then there is no way to see the toolbars for a window without the input focus without clicking in it.

Clicking doing nothing would be a surprise for me. I don’t expect it in text editors and I don’t expect it in sprite editors.

I think the best idea is to avoid hiding toolbars.

That’s a ColourPicker suggestion, not a Paint one.

Sure, but that’s a technical differentiation. It’s completely irrelevant from the point of view of improving Paint’s user experience, because the colour picker behaviour is integral to Paint usage.

UI elephant in the room … click of surprise … why would we preserve that disfunctional UI?

I disagree with all of that. I don’t like clicks in the window failing the first time round. Panes hanging out the sides of the window end up obscuring the window when the window is against a screen edge. I don’t mind having multiple colour pickers open at once. Actually, I often use that fact to ensure I set the same colour in the sprite I’m working on as I used in another.

The reason I frequently use Paint is because it’s the best editor for simple pixel work I’ve encountered on any platform. I really don’t want to see its behaviour completely redesigned but I’m all for changes that streamline current usage or fix bugs.

The single biggest problem with Paint that’s been mentioned in this thread so far is really the lack of Undo.

There are two separate issues here, it seems to me:

1. Input focus. At present, clicking on a sprite editor window performs some action straightaway. If we want key shortcuts, then this will need to change to the first click claiming the focus, and subsequent clicks performing actions. That’s different to a click ‘failing’, since there’ll be a visual change to the window. It also addresses the ‘click of surprise’ issue.

2. Toolbars, etc. The balance of views in this thread at least seems pretty clearly against having attached toolbars and/or palette windows. Although you’d probably want to implement (1) in order to achieve (2), you wouldn’t have to, so I think they’re separate things.

I’d be in favour of (1), since it opens up a useful range of standard shortcuts (F8, etc.). I’m happy to go with the majority on (2).

1. Input focus. At present, clicking on a sprite editor window performs some action straightaway. If we want key shortcuts, then this will need to change to the first click claiming the focus, and subsequent clicks performing actions.

I suppose so, but needing to double click to set a pixel colour the first time you return to that sprite window may take a bit of getting used to. 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. In fact, recent versions of DigitalCD had a bug which meant its playlists behaved in this way – if you tried to select an item in a playlist which didn’t have the input focus, it would be immediately deselected. As playlist windows don’t tend to spend a whole lot of time with the input focus, the effect was to force double- or triple-clicks for everything. It was very tiresome.

The ‘click of surprise’ would be better mitigated by the standard paradigm of changing the shape of the mouse pointer while it is over the window to match the selected tool. While I don’t think I’ve ever had such problems in Paint, it would probably be an improvement in any case.

Can’t remember if this was covered or not: replace the insert/delete columns/rows menus with buttons in the toolbox, which work by drag and drop (like the copy/move/cut) and some indication of the precise number of columns/rows inserted/deleted so far (preferably with a number displayed beside the mouse pointer).

Come to think of it, something which would be really helpful and relatively simple: make all the drag and drop operations support autoscrolling. There are many things it is physically impossible to do with them at the moment because you need to be able to get the entire area on the screen at once, which is often just unreasonable.