One of the most regularly requested 'features' for RISC OS was that of a global clipboard. Most often the response to this was that RISC OS already has a definition of a global clipboard that applications can use - and had since about 1992. It didn't answer user's questions much, but at least pointed a finger at applications developers for not using the protocol that was created to address the issue. In many cases, the reason that developers had not implemented the clipboard protocol was that it was extra work and very few applications supported it - and like many things of this type, that would only change as people started to use it.

I believe that the clipboard and selection protocol came out of work for Acorn Advance, which integrated a number of packages together with a set of coherent protocols. This made the package into a more integrated suite, and made it more than it otherwise would be. And those packages got some nice protocols with which you could work. It is quite closely related to the drag-and-drop protocol, which was also created for Acorn Advance. Both were published as Acorn Support Notes (thanks to David Thomas for the reminder about the history here).


Prior to working for RISCOS Ltd, my own libraries had begun to use the clipboard protocol. My main display library within !JFShared, DispLib, provided support for highlighting selections, and copying them to the clipboard. Essentially this meant that any of the applications that used the library could very easily support the protocol, without much intervention.

As well as implementing the protocol, I had also reviewed the different clients of it, producing a list of the applications which supported the protocol and how well it was handled. The list was useful to gauge how widely it was available. Actually the protocol was used in a lot more applications than I had expected. The list that I posted up on usenet shows 22 applications, including the main word processor / DTP packages.

Although that may not seem much, especially as this was in 1999 - 5 years after the protocol had been published - it was a reasonable selection of the applications. Some of the criticism about the protocol was levelled at the applications supplied with the Operating system, which didn't use the protocol at all.

Part of the reason for that was that those applications were not being developed any longer - aside from bug fixes, they weren't really being touched by anyone.


The ClipboardHolder module was initially created to implement an application that could take over management of the clipboard when other applications exited. This part of the protocol was developed by Acorn as part of the NCOS work to alleviate the issue that applications would run in full screen mode and when finished with they would exit - taking the clipboard with them.

Exiting applications broadcast a message saying they are releasing the clipboard, so that other clients can pick it up. The ClipboardHolder requests the clipboard and holds on to it.

Since the ClipboardHolder performs this task, and other applications may want to use the clipboard, but not care for the complexity of using the (actually quite simple) protocol, it also provides a couple of SWI calls so that applications can manipulate the clipboard. Mostly this is useful to copy content to the clipboard - thus handing off all the 'paste' handling to the ClipboardHolder module, and making the application's implementation a little easier.

During the development of the ClipboardHolder, I also tinkered with the idea of announcing the clipboard contents over Freeway, so that it might be requested by other hosts. Although the actual transfer wasn't implemented, the announcement worked ok. I decided it was a really bad idea and abandoned the work, but it was a vaguely interesting extension that might have been useful in a few (rather limited!) contexts.


Application icon for !Clippy

Early in post-RISC OS 4 development, I wanted to offer more clipboard operations - which is why the ClipboardHolder was being updated at that time. However, having a visual indication in the desktop itself would make it clearer that the clipboard was being used. I wanted to have a simple pop-up window which showed the type of data, and maybe a view on to its contents. I got as far as writing a basic application which would appear on the IconBar, showing the clipboard filetype pinned to a clipboard.

It wasn't the most impressive of applications, but it provided an idea of what could be done with a user interface component to present the clipboard. The work was abandoned, though, because there was generally no need to see the clipboard contents in this way - certainly few other systems ever did so.

On the other hand, it was pretty nice to copy text to the clipboard and see the icon fill with a text icon, and then copy a DrawFile, and the icon would be replaced by a DrawFile icon. It amuses me anyhow - I'm quite easy to amuse.


During the development of Ursula, Acorn had examined the problem of adding selections to the WindowManager - which would allow text in writable icons to be selected. They specification that Ben Avison wrote was really quite nice and sensible. I don't seem to be able to find the document in my reference directory, but I remember it being all pretty sensible. I aimed to implement most of what was in it, with the exception of multiple window selections (that is, greyed selections for unfocused windows). That decision was mostly for simplicity. I was also unsure if it was really the 'right' thing to do, as Filer didn't do that, and it added an extra visual cue to remember within a window - not that I had a strong opinion over that of it being more work.

In implementing the selections, I started from the most visible part - as that gave the easiest way to see if the changes would work. The selection highlighting was implemented in part of the icon rendering code, just by matching some given parameters. Adding a couple of values to the workspace to indicate the start and end of the highlight, and then using them on every single icon redraw meant that I could have a Wimp running and poke the values into the workspace directly, then cause a redraw of any icon to see if the redraw was doing what was expected.

The handling of all of the caret code was updated quite a bit to try to make it easier to work with. A lot of places used hard-coded constants to reference structure offsets, which made it harder to move the structure around - and usually you found that there was another constant broken when you moved the base structure around, only to discover the Wimp aborting when you did some operations. I guess some of those problems were due to the age of the code and maybe the caret data didn't have any proper constants at all initially.

The selections themselves used the background colour manipulation in the icon plotting code to provide the means to highlight the background. As the font plot string was constructed, the colour command sequence would be inserted into the font strong depending on whether we were entering or leaving the selection. This is the main reason why the system font does not support the use of the selections.

Selection in the simplest window I could find
Selecting text in a dialogue box.

Making selections wasn't that hard, as the FontManager's SWI Font_ScanString function provides all the information necessary to work out the position of a click - and that's already been done by the click handling for the mouse anyhow, so the code could be reused. Selections using the keyboard were more difficult to decide, though.

I really wanted to use shift-cursor left/right to make selections, as this is used in most other systems, except that shift-cursor is word-step in RISC OS. Faced with removing word-step, or moving it to shift-ctrl-cursor, I decided that the most sensible course of action was to leave the current key input as it stands, and use shift-ctrl-cursor for the selection. This should have the least user impact, allowing users to use the system exactly as they had in the past, but also have selections without too much problem.

The issue of what to do with the caret was also difficult. Ben's specification was that there be a caret or a selection, but not both (if I'm remembering right). This made text selections through the keyboard harder, so I opted to keep the caret. It isn't easy to see which end you're manipulating through the keyboard if you don't have a caret to show where you are currently. It raised the question of where the caret ends up if you make the selection by the mouse - I chose the point of the release, as that seemed most intuitive.

There was also the similar the issue of what happens if you move the cursor whilst the selection is active. What happens if you type something whilst there is a selection active ? What happens if you press delete whilst there is a selection active ?

All of these were easy to solve together - make them all configurable so that the user could make them do what they wanted, or match other systems that they might be used to. Leave the defaults as those which are the most obvious (at least to me).

  • Move - clears the selection.
  • Insert character - deletes selection, replacing it with the character.
  • Delete - deletes the selection.

There were actually more than just these two operations - you could configure 'delete' to cut the selection to the clipboard, or to do nothing, which would mean that the selection (or text) would shrink as text was removed. Same goes for insert, so you could insert text into the middle of the selection (which only really worked if you also allowed movement by setting its configuration to 'none').

Because Windows does it (and I'm a great believer in the principle of least surprise), the option was also available to select all the text in an icon when the caret enters it. However, because it annoyed me (and also it would be a significant change in behaviour for RISC OS users), the default for this setting is to be disabled.

Cutting and pasting text was achieved via the ClipboardHolder, which also had a small modification to always claim clipboard items that claimed to be text. This meant that the module always had text available for pasting into icons if anyone requested it.

The usual RISC OS key combinations were used for the clipboard operations in the icons - Ctrl-C to copy, Ctrl-X to cut, Ctrl-V to paste, Ctrl-A/Z for select all/none. This raised the issue that the keys wouldn't be passed to the application for its own handling - and it might want those keys.

Since the use here was not really reconcilable except by providing an option to disable the clipboard all together (which seemed like it wouldn't really be a useful solution), and the number of applications that would be affected seemed to me to be very low, I decided to merely provide a way to disable the clipboard behaviour on a per icon basis. By using the KC validation, the clipboard could be disabled on an icon.

I'm not certain that it addressed all the issues, as it did mean a change to applications (or maybe just templates) to change the behaviour, but for such a generally requested feature, it had to be available widely. A couple of common applications were seen to have this issue, and the authors were contacted to let them know what was happening. As the only change should be a minor update to the templates it wouldn't be a particularly arduous issue to update them.

The SWIs to set the caret position were extended to allow control over the selection - which I'm pretty certain was an original specification from Ben's document. A new SWI Wimp_DragBox API was created so that clients could activate text selection boxes. There was also an API using SWI Wimp_ReadSysInfo to read the configuration of the selections, so that applications that wanted to do things a little differently could do so and still match the user's configuration.


Application icon for !WindSetup

The configuration tools had to be updated to create configuration for the new options, so a new section was added to !WindSetup, alongside the Icon settings, for 'Text selection'. All implemented with glorious !Help support as well (which I'm pretty sure that nobody paid the blindest bit of attention to - I know I rarely did with new applications).

Of course the *Command to configure it was provided by the Wimp for configuring - *WimpTextSelection -bg &813979 -fg &FFFFFF - purple selection backgrounds!

!Paint, !Draw, !Edit

!Paint was updated so that it could copy a sprite to the clipboard, and also to paste from the clipboard. Similarly !Draw was given clipboard operations that could be used either to copy to itself - the key bindings were updated in !Draw to make the clipboard the default - or from other applications. You could cut a sprite in !Paint and paste it in to !Draw quite happily. Or you could do the converse - copy or cut an object from !Draw and paste it in !Paint - due to the ImageFileConvert/ConvertSprite handling of DrawFile to Sprite conversion.

!Draw wasn't quite as nice when it comes to text, because it pastes as a text area, which are really not that useful at all. But still, it does work.

!Edit was also updated so that you could cut and paste using the clipboard, although strangely Ctrl-A seemed to be left inserting [01]... bizarre. But on the other hand, the supplied applications are often the ones that get the short straw, becoming the last things to be updated. It was really quite good to see that they actually got the features not long after they were available in the Wimp.

Not quite sure why clipboard wasn't added to !ChangeFSI - maybe I just didn't get around to it, or maybe it wasn't all that interesting. It's not really all that useful in there.