Text and Sprite on a Menu Item

I’m making a menu for Paint that lists brushes. I want each menu item to include a small sprite of the brush and the name of the brush sprite alongside it.

Unfortunately, the icon data only allows an icon to have both text and a sprite if the sprite is in the Wimp sprite area. I’d much prefer that the brush icon sprites were stored in one of Paint’s own sprite areas. If they go in the Wimp sprite area, the names could collide with a name of a file type or application, either changing the user’s file or application icons on the desktop, or making icons from another application appear on Paint’s brushes menu!

What’s the best practice to solve this?

1. I think my easiest option is to load the sprites into the Wimp sprite area using obscure names (perhaps leading underscores followed by “Pnt” and a number).
2. If I put them in a different sprite area that I specify in the icon data, then I can’t include text with that icon. I could render the text into the sprite; if I did this, how would I determine which font and size is currently configured for the desktop?
3. The hardest option would be to build my own window as a menu; I don’t want to do this as it seems like it would be tricky (and a lot of code) to implement the menu item highlighting, ticks and dynamic layout.
4. I was even wondering if I could generate custom characters to represent the brush sprites so they can be displayed as text but this doesn’t seem too viable (as I guess it’d have to be in a copy of whatever outline desktop font the user had configured, and the system font, and I’d have to choose some characters to replace that can’t appear in sprite names, and then I’d want to hide my custom font from the user!).

What should I do?

I think my easiest option is to load the sprites into the Wimp sprite area using obscure names (perhaps leading underscores followed by “Pnt” and a number).

This is probably the best option, but not the bolded bit.

Allocate has provision for requesting WimpSprite reservations when the “bundled” ones (filetypes, application directory) don’t suit. It’s under Reservation, where Type is WimpSprite. You would allocate the name of each sprite individually.

PS. Given the way the system works, you would probably need to be clear in the covering email that you were allocating the names for Paint, and for RISC OS.

Thanks Steve. I must say I learnt about these “text with sprite” icons from your excellent website! I’m not sure allocation requests are the best option here because Paint currently has four different built-in brushes which I’m thinking of expanding quite a bit, and on top of that I’m remembering recent sprites the user has made into brushes. That said though, I’m setting an upper limit of 40 brushes to display on the menu, so I suppose if I could get resource allocations for 40 unique names, I could reuse the names by reloading the sprites every time the menu contents changes. It does feel somewhat extravagant though.

I’d layout the brushes in a window template and open the window as a menu. This avoids poluting the wimp area, gives you the option to open the window persistently so that it doesn’t disappear when trying out different brushes and leaves the option open to extend it later – I don’t know possibly add a slider to to vary the diameter of a brush.

I want each menu item to include a small sprite of the brush and the name of the brush sprite alongside it.

Why the name of the brush? Artistic use would surely be more concerned with the shapes than what they’re called.

I think my easiest option is to load the sprites into the Wimp sprite area

As long as they’re small. You can’t really remove sprites once they have been added (well, you can, but it’s a hack by using Wimp_BaseOfSprites and SpriteOping the address returned…)

how would I determine which font and size is currently configured for the desktop?

You don’t.
Wimp_ReadSysInfo 8 will return the handle of the desktop font in R0 (note: 0 if VDU).

SYS "Wimp_ReadSysInfo", 8 TO f%
IF (f% = 0) THEN PRINT "VDU font" : END
SYS "Font_Paint", f%, "This is a test in the Desktop font...", (1<<11) + (1<<4), 256, 512
END

To know what the actual font used by the Desktop is…

SYS "Wimp_ReadSysInfo", 8 TO f%
REM Trap f% = 0
DIM n% 63
SYS "Font_ReadDefn", f%, n% TO ,,xp%, yp%
PRINT "Desktop font is "+$n%+", size "+STR$(xp%/16)+"x"+STR$(yp%/16)+" points."

I’d layout the brushes in a window template and open the window as a menu.

+1

It’s sort of how PhotoDesk does it. After a selection of round brushes in various sizes, you get some really weird shapes…

Imagery is similar, but vastly less sophisticated:

Edit: Grr… Textile… Grr…

I must say I learnt about these “text with sprite” icons from your excellent website!

Um. <blush>

In that case, it might be worth bearing in mind that there’s a significant chunk of detail missing from the site, which includes how to make text+sprite icons read their sprites from an application’s sprite area. I actually started writing that chapter this morning, genuinely coincidentally. :-)

That said, it doesn’t help for a menu, because you have do to it at a window definition level and the Wimp hides that from you when it makes menus up.

I have to say that I’d agree with Rick and Colin on better UI approaches. There are many things that you can do with menus in RISC OS, but probably shouldn’t. :-)

Why the name of the brush? Artistic use would surely be more concerned with the shapes than what they’re called.

That’s the final ideal for a brush tool, yes. At the moment what I’m making is more of a stop-gap, that integrates with Paint’s traditional interface of “use sprite as brush”, so you’ll still be able to type in a sprite name if you want to, and see the names of any sprites you drag onto the tool. One particular case where the name is useful is if the user makes brushes from very large sprites. They’ll be scaled so small on the menu that they may be indistinguishable except by name.

I was also considering that if I do end up putting the buit-in brushes in the Wimp sprite area, I might just cop out and use the sprite file icon to represent the user-created brushes. I probably won’t do that, though.

In that case, it might be worth bearing in mind that there’s a significant chunk of detail missing from the site, which includes how to make text+sprite icons read their sprites from an application’s sprite area. I actually started writing that chapter this morning, genuinely coincidentally. :-)

The PRM filled in the gaps for me. The PRM doesn’t explain the general concepts as well as you do.

That said, it doesn’t help for a menu, because you have do to it at a window definition level and the Wimp hides that from you when it makes menus up.

I’d already got it working (with the Wimp sprite area), but then the menu items were made by RISC_OSLib… Edit: Never mind; I see what you mean now.

I have to say that I’d agree with Rick and Colin on better UI approaches. There are many things that you can do with menus in RISC OS, but probably shouldn’t. :-)

I shall consider myself thoroughly forewarned, and probably wind up doing something unconventional anyway!

so you’ll still be able to type in a sprite name if you want to

Yes, that’s useful for pasting sprites together. ;-)

[imagine: generic scenery, masked playmobil person, etc etc → final scene]

so you’ll still be able to type in a sprite name if you want to

One advantage of removing the user-typing-a-name option is that you’ll lose the writable icon from the Tools pane, which will have the happy side-effect of not nicking the input focus (yes, that old hobby horse…). For that reason, as well as simplicity, I’d be in favour of the interface removing the writable icons and just offering something like a pop-up list or grid. Displaying the sprite name next to the selected sprite is a good idea, though, as you point out.