Toolbox: multi-line icons

I have a Toolbox-driven window in which I want to display an error message. Currently this is provided by a display field, and if the error message is too long it spills out the right and left sides of the icon. I have the length set to 256 and justify set to centred.

Is there a way to make this a multi-line icon? ResEd doesn’t give me an option to do that.

I also tried turning it into a text area, but that looks and behaves like a writable icon except with ‘display only’ ticked you can’t type in it (but you get a caret). The text is left justified, and I can’t see a way of changing that. The icon is also flat using Corpus font, not slabbed and in default font.

Worst case, I can insert line breaks in my text. Do the icons accept them?

Is there a way to make this a multi-line icon?

Try a button gadget, set button type to “never”, set validation to “L;R2”, set the text and text length as desired, make sure sprite in unticked.

Try a button gadget

Yes – that is essentially what I have done in the past for a multiline display field.

Text areas should (IMHO) be able to be used for this sort of situation. ROL’s TextArea gadget is far superior to ‘ours’, but when I suggested improving the ROOL Toolbox modules to match, the general opinion seemed to be “why bother, everyone uses ROL’s modules anyway”.

Maybe it’s time to revisit that, it’s something I’d like to do when I have some free time.

The problem as I see it is that “everyone uses ROL’s modules anyway” is not true. You cannot assume anything about what Toolbox version someone has installed, or is willing to update to. The only answer, until there is some cooperation between the branches, is to assume the lowest common denominator. Even the presence of the 2003 ROL set cannot be relied on.

This is a terrible waste of the effort that has gone into the ROL branch, and third party developers.

This is a terrible waste of the effort that has gone into the ROL branch,

I know that this is probably the elephant in the room that no one is supposed to talk about, but:

Doesn’t the development licence (current by Castle) and (historic by Pace) require the developer to feed back the development source to the owners of the IP and head licence?

i.e. Should the source for the ROL developed items be in the Castle source repository?

Rik:

the general opinion seemed to be “why bother, everyone uses ROL’s modules anyway”.

[citation needed] :-)

For what it is worth, I pretty much pretend the ROL branch doesn’t exist. It isn’t for any specific like of ROOL and/or dislike of ROL, it is pretty much because I see one branch of RISC OS continuing, and the other… not.
Who wants to back a losing horse?

Steve:

This is a terrible waste of the effort that has gone into the ROL branch, and third party developers.

Couldn’t agree more. It upsets me to think of all the work ROL has put into RISC OS, and what will become of all of it? We, on the other hand, will need to either reinvent the code, or do without. There is, of course, the problem of API changes if we do it (for example: would Justin’s extensions to OS_Mouse scale for the likes of graphics tablets and multitouch display sensors? how would such things be reported to applications? if we were to revise the “user prodded us here” API, it would make sense to consider the possibility of such hardware…).

Anyway, in essence, there’s a RISC OS in active development. That’s the one to work with.

Other Steve:

Should the source for the ROL developed items be in the Castle source repository?

Oh boy… Batten down the hatches!

:-)

(for example: would Justin’s extensions to OS_Mouse scale for the likes of graphics tablets and multitouch display sensors? how would such things be reported to applications? if we were to revise the “user prodded us here” API, it would make sense to consider the possibility of such hardware…).

You mean a tablet that used to present itself as one thing and now presents itself as a “ROPad”? That type of thing?

Oh boy… Batten down the hatches!
:-)

I did say it was the elephant in the room no one talks about.

Doesn’t the development licence (current by Castle) and (historic by Pace) require the developer to feed back the development source to the owners of the IP and head licence?

Only for the first four years

The problem as I see it is that “everyone uses ROL’s modules anyway” is not true.

Indeed. In fact the wilful lack of backwards compatibility (and pointless make-work) exhibited by ROL is what led me to decide not to support them in any way.

For what it is worth, I pretty much pretend the ROL branch doesn’t exist.

Indeed.

Thanks folks, the L;R2 button works nicely.

Theo (a surprise convert to C++ and the toolbox)

For what it is worth, I pretty much pretend the ROL branch doesn’t exist

That’s very shortsighted, as there is a lot of good stuff in there that would be very useful to have in RO5. Sadly it will probably have to be reimplemented unless someone can persuade ROL to release their code.

oink flap oink flap

Like what?

Like what?

Support for 64K colour modes would be nice. And by looking at the changes they had to make we can easily spot which bits need changing in order to add support for even more pixel formats (64K is just the tip of the iceberg as far as extra pixel formats go). As things currently are it looks like we’re going to have to waste a lot of effort rediscovering what needs changing for ourselves.

I think it can be easy to dismiss certain enhancements as needless and cosmetic, but as someone who has used Select for some years I can honestly say there are some things that I miss hugely. From the more cosmetic (thumbnails in the filer) to quite significant (ImageFileRenderer). For example, Fade runs much faster using ImageFilerRenderer than when forced to use ChangeFSI.

The so called bells and whistles that are there out of the box shouldn’t be dismissed either. Sure some can be added via third party extensions but that is far from ideal. And don’t get me started on the Toolbox…

The thought of all that development effort going to waste is very frustrating.

And don’t get me started on the Toolbox… The thought of all that development effort going to waste is very frustrating.

!!!!!

The ‘development effort’ comment wasn’t directed at the Toolbox, but at the OS as a whole….

Support for 64K colour modes would be nice

Well that’s not brain surgery, but is it needed? The days of 2MB maximum Video Memory are long gone surely?

I’m not being snarky, I really don’t know what the feature list is.

Well that’s not brain surgery, but is it needed? The days of 2MB maximum Video Memory are long gone surely?

It’s not about getting more colours of the same amount of VRAM; it’s about making sure RISC OS runs properly on new hardware:

• Early models of Iyonix had modified graphics cards to cope with the fact that they use RGB ordering instead of RISC OS-friendly BGR ordering
• Later models of Iyonix (FX-series cards) were able to swap the red & blue channels in hardware, but only in 32bpp modes. Result: No hardware modding needed, but corrupt 16bpp modes.
• OMAP3 natively uses RGB ordering instead of BGR. Luckily for DVI output we can use the colour phase rotation matrix to swap the red & blue channels over, but for TV out we’re stuck with BGR.
• OMAP3 doesn’t have a 5:5:5 16bpp format; it only has 5:6:5 RGB and 4:4:4:4 ARGB (and true 12bpp 4:4:4 RGB, but that’s the least likely to be adpoted). For DVI output I was able to use the gamma table to remap 5:6:5 into 5:5:5, but it results in only 4 bits of blue instead of 5. For TV output there’s no gamma table, so we’re stuck with using an OMAP-native format, which means colours will currently be garbled.
• Raspberry Pi doesn’t have a 5:5:5 16bpp format, it only supports 5:6:5 RGB, similar to OMAP. There aren’t any gamma tables for us to play around with, so for the moment 16bpp modes are disabled to stop people being put off by the corrupt display.
• It’s also worth pointing out that the Pi native RGB ordering is also RGB, but luckily the GPU is able to swap the red & blue channels for us. However I’m not sure if this is only supported in 32bpp modes or whether it’s supported in all modes.
• RISC OS may also have to be taught to exert more control over the alpha/opacity channel of a pixel in order to cope with hardware which can’t be told to ignore the alpha channel (or for situations where we want the alpha channel to be used, e.g. video playback in the desktop, with the video overlay under the desktop overlay to allow windows to overlap the video player)

Although not directly related to the above issues, it’s also hoped that method used to describe these new RGB formats to the OS APIs will also be suitable for describing YUV formats, providing us with a unified way of describing the pixel format of an image/hardware overlay.

For someone who seems to always be talking about how things need to be changed, I’m surprised this isn’t an issue that you’re already aware of.

There are a few other ROL features of interest that I don’t thing RISC OS 5 doesn’t have yet:
- Select, copy and paste text in icons.
- Background error handling (i.e. avoid killing the current application because an interrupt or callback crashed in the background).
- Filer and dustbin integration (Delete moves a file to the dustbin, Shift+Delete deletes the file).
- the ROL Mimemap modules sorts the mappings so that wilcarded mappings are always checked after non-wildcarded ones, allows to specify “-” as a mimetype when you just wishes to map PC extensions with no known mimetype to a RISC OS filetype, and supports “Mac” types (IIRC for the AppleTalk module).

I can honestly say there are some things that I miss hugely.

We all have our pet likes/dislikes. Sometimes for silly things too (my current Android phone doesn’t have an RSS reader, for instance). I think changing systems (even to the same OS on a different machine) is problematic as you’ll remember how the old machine used to work and get irked if the new one is different.

From the more cosmetic (thumbnails in the filer)

Had that until the Beagle – Filer+ on the A5000 and FilerPro on the RiscPC. Talk of Filer enhancements, Thomas Olssen did it years ago…

to quite significant (ImageFileRenderer).

Is that derived from ImageFS?

The thought of all that development effort going to waste is very frustrating

Well, it was likened a few days ago to the elephant in the room, but I consider it more a hyperactive diplodocus that we’re all trying not to notice. When I talk to some people about it, things get a little…frosty. Perhaps they’re equally annoyed at the amount of time and work that went into…I would hesitate to call it a dead-end fork of RISC OS, but I don’t see much going on with it right now.
It is a crying shame, for sure. Will any of that hard work find its way into the currently-developed version of RISC OS? Look up for Bryan Hogan’s post…

:-(

While misremembering ROL’s website, I found www.riscos.co.uk pointed to a UK2 holding page. A domain lookup was interesting, giving the person as Alan Robertson at an address in Glasgow…then Bulgaria. Huh?
First registered in September 1999, re-reg’d in November 2011 through to September 2013. Anybody know who this is or if there are any plans for doing anything with that domain?

Funnily enough, Justin was discussing toolbox modules with me this morning. I hope I’m not treading on his toes repeating this, but as far as he is concerned, the Toolbox dev was supposed to have become aligned about 5 years ago – ie. he submitted his toolbox module stuff such that one definitive set of Toolbox modules could be maintained.

This seems to have gotten lost somewhere between RISCOS Ltd and Castle/ROOL :(

It is a great shame, and possibly something worth checking into, as it would seem the hard work (getting people to agree to things) was done! Indeed, Justin seemed rather miffed that nothing had come of this, as he was keen for more people to use the Toolbox, and thus gain access to the additional features he was adding.

For someone who seems to always be talking about how things need to be changed, I’m surprised this isn’t an issue that you’re already aware of.

I’ve only used emulators for the last decade and have been far from this ‘scene’. I have literally no idea about any current hardware requirements, and your list very interesting.

However, I was really asking about the application-facing API differences between the current ROL and ROOL builds and UI features the user would notice, not back-end differences related to hardware porting (which, though essential, I have no interest in nor contribution to make).

André wrote:

• Select, copy and paste text in icons.
• Background error handling (i.e. avoid killing the current application because an interrupt or callback crashed in the background).
• Filer and dustbin integration (Delete moves a file to the dustbin, Shift+Delete deletes the file).
• the ROL Mimemap modules sorts the mappings so that wilcarded mappings are always checked after non-wildcarded ones, allows to specify “-” as a mimetype when you just wishes to map PC extensions with no known mimetype to a RISC OS filetype, and supports “Mac” types (IIRC for the AppleTalk module).

Thanks. Cut & paste is certainly essential.

Error resilience also long overdue (I was wondering about this last night – should RO not go to more effort to remove vectorclaimants/callafters/callbacks/soundvoices that reside in memory known to be invalidated by OS_Exit, OS_Module and OS_Heap calls… to say nothing of bracketing such background stuff to avoid repeated errors).

I’d prefer Filer extensions like that to be via some hook, rather than built in. (I prototyped a Filer that supports Windows-like filetype-contextual entries on its menu, harvested dynamically from sysvars).

As for MimeMap, I definitely implemented that (a very long time ago there was some talk of writing open source ROL compatible modules, so I started with something easy).