Ah, the Filer. There are so many ways that the Filer can go, but some of them have already been tried. Different systems need different interfaces, and strictly the 'filer' interface does not need to be the way that it works in RISC OS. So long as the operations that it can perform and the interfaces that it uses are the same, it could be presented in a different way. The changes that I had made for panes were partly inspired (if you can say that) by the interfaces provided by other systems for docking additional toolbars into applications. The Windows explorer is a typical example, but not the only one - browsers provide similar functionality and the nesting provided by the WindowManager encouraged it.
The main issue with changing the Filer is that of user acceptance. There are many things that can be done, but as a lot of focus in RISC OS is placed on the Filer, it has to be useful for users. As I have said a few times, there have been minor things that have changed which have caused users to just reject the upgrades outright. That is obviously their decision, but the Filer being so central means that this is more likely to happen when changes are made to it.
This said, the changes that had been made were in line with the functioning of the system as a whole and the Filer itself. Keyboard support had been widely requested, but it brings a whole collection of interaction decisions which have to be resolved or people won't want to use it. In particular, how to give a focus to a Filer window without breaking the habits formed for some applications. For example, it might be common to make a selection in an application, and then navigate to a location in the Filer in order to save that selection. If the application forgets the selection when you lose the focus, then the act of clicking on the Filer window giving it focus breaks that use case.
This was the primary reason in my development builds for the keyboard focus being an alt-click operation. I didn't like that, but there isn't a lot you can do about it if it directly breaks application uses. In the final version I might have ignored the breakage, as it is probably not as significant as you might expect, but it would have needed more thought. Another possible way to address that particular problem would have been to implement some form of focus 'stack' so that the focus could temporarily move to the Filer before returning to the application. This would help in other cases as well, and I had previously experimented with filters that performed this form of stacking on behalf of applications, and even with dedicated application support.
It was never particularly successful, and the cases where the automatic menu focus occurs, merely complicated things. This could, really, be coupled with the general problem of keyboard support in the system, where the menus themselves could get focus and be navigated without the mouse. This had been partially implemented, but wasn't at all reliable.
If we are using the keyboard for selections, how does that leave the interactive help system, or the aforementioned tooltips protocol ? In some cases the !Help system could be made to work by changes to the requesting application, but obviously that would only work if the requesters were updated. The tooltip protocol was nascent, so thought would have gone in for this up front, but it made that problem a little larger.
The Filer's use of cut and paste was another area which made me pause. There was no such operation in the Filer previously, and the operation did not really fit with the Clipboard protocol. The protocol is only intended for operations on content, not on files, or collections of files. As such, there is no way to represent in the clipboard that a 'file' has been cut (or a group of them), nor to associate any name with the content. If I were to cut text from an icon and then paste in a Filer window, the most obvious result would be a text file to appear. Ok, but what do you call it ? I had thought about doing this sort of thing using a standard name (localised, of course) of 'Clipboard' or 'Selection', but what happens if the file exists ?
Going the other way, assuming you had done this, you would expect that copying that file, and then pasting in an icon would put the content of the file into the icon. That is not that hard, but what if the content of the file is large, do we copy it to memory only to find it does not fit ? That is one of the simpler problems as it is only implementation.
What if we copied a directory in the Filer and pasted it into an application ? Is that the same as if we had selected a circle in !Draw and tried to paste into a text editor ? Probably. How about a group of text files being selected ? Is pasting them into an icon going to concatenate their content ? Or be rejected ? If the application you were pasting into was Pinboard, can it know that they are just shortcuts - the clipboard protocol does not have any concept of that. Or even between two Filer windows, which is the most common of the operations.
I had considered a special filetype '
to be registered) which contains the list of the files being operated on. It
would be this that was copied to the clipboard, and would be acted on
differently by applications that understood it. This would allow the names
to be preserved properly, and shortcuts to be made appropriately (for
Pinboard). There might need to be a separate change to the clipboard protocol
to non-destructively terminate the operation safely - in the case of objects
that had been 'cut' in Filer, but pasted in Pinboard (which provides a
shortcut only) the 'cut' needs to be cancelled on completion, otherwise the
data has been lost.
You might argue that the 'cut' should only be used when the 'paste' operation was in another Filer window, as the operation becomes a file rename/move, but that precludes the use of non-Filer applications acting as Filer-like applications - think of an archive or packaging application.
Although cut and paste are mostly introduced because of the Filer, they do not necessarily need to be tied to it - the menu structure could be augmented to include extra operations, or replace the existing ones. Having old-style copy/move and new style copy/cut/paste on the menus might very easily become confusing, though.
Essentially the issue of keyboard use in the desktop needed more thought, and whilst the support was available in the Filer, it wasn't really in a shape that you would feel comfortable with.
The Filer's menu structure had been fixed for quite a long time, with the only significant additions that we had made over the years being to extend menus at the bottom (set work directory) or divisions (thumbnails). In the case of the 'Set work directory', it wasn't actually at the bottom, but above the 'open parent' entry, to ensure that the habit of 'select the bottom item to open the parent' was still there. I am certain that decisions like that were better for the general user, so long as the menus didn't increase to silly sizes.
Over the years many people had requested menus which changed dynamically depending on the things that they operate on. It is one area that RISC OS has staunchly avoided, and which I find frustrating. With the exception of changing due to the mode you are in (for example if you are in an 'editing' mode you want different things to being in a 'view' mode), menus retained the same shape. Instead of options being removed, they would be greyed out. This becomes difficult if you have large numbers of operations available, but generally it is a good plan. The concept of changing the Filer menus depending on the content was not unreasonable given the things that it would open up, but I felt quite strongly that the style used by RISC OS was opposed to such things.
I had tinkered with dynamic type menus, and even with adding new items to the end of the 'Selection' menu, but even this felt like the wrong sort of direction. I had not made an absolute decision that it never be done, but I had started to form the thoughts that if such things were going to be possible, they should be done in a structured manner and not used by the system as distributed - that is the capability would only be available as an extension (registration or similar) to the Filer used by third parties. That meant that the interface had to be sufficiently structured to allow other Filer-like implementations to also support it.
I had considered having a module whose sole purpose it was to manage the interaction of such extension menus (what to do when things are selected, how they respond to interactive help, whether they have dynamic sub-menus, etc). That would mean that the Filer would also just be a client of this other menu manager. There are still holes in the thinking, but that was the way that I was considering, if I had gone any further on it.
The Filer panes were functional, but it was harder to embed vertically stacked side-bars. I wanted to resolve that issue, as it made a lot of sense to allow multiple side-bars to be present in that form, rather than all stacking across the window, which did not look particularly appealing. Quite how that was going to be done - the Filer would need to negotiate a common width for the side-bars and communicate that, where there was no way to pass that information back around at present.
The pane functionality had really only just started, so it wasn't clear how it would be best used. It is very likely that any extra work on them would be driven by developers trying to use it and finding restrictions, assuming that anyone did. I don't really hold much hope that anybody would have done so.
The Filer ordering was modified in (I believe) Select 2 to change the character based sort to alphabetic and numeric, so that files were ordered 1, 2, 10 rather than 1, 10, 2. This was, I believe, a good choice, but I had wanted to make it a selectable option. However, the sorting modes selectable are restricted to just 2 bits, which means that there is no room for another sorting order, or option. If we wanted to sort on anything name, type, size or date, it was not possible. I believe after I stopped doing things on RISC OS, someone added support for changing the order from horizontal to vertical. I do not know how they managed to fit that into the bits - as I recall there were only 8 bits for the view options and 6 of those are already used. I guess that could be added as a separate bit, leaving just one spare.
In any case, I wanted to extend the way that information was presented in the Filer, to allow additional fields to be shown in the full information view, and to be sorted on (and possibly filtered). Quite how that would work, I wasn't sure, but again I had considered using a separate module to perform the directory enumeration and metadata collection. One downside of that was that it would need back-channel in order to collect metadata in the background. Metadata, in this case might be as simple as 'time stamp in a photo', or may need to be looked up in a database (eg 'date file was deleted' for rubbish bin viewing).
I was thinking of a registration interface for providers of data readers. In some respects this complements the ImageFileRender stack, but targeted at embedded data. It would need to be managed in a sane way so that such providers would not make the system significantly slower, or incur greater file access overhead. Using some of the data types provided by the Internet statistics enumeration would help significantly in allowing the presentation of the data (and its sort ordering) to work usefully. Obviously the types in that specification are heavily focused on network statistics, so there would need to be a more data types to cover the other formats (for example, dimensions, bit rates, or owner). The storage handling inside the Filer provides for a reasonable degree of flexibility, so changing to use other data wouldn't be too hard.
Having a registration interface, like the previously mentioned menu extensions, would allow other clients to use the data it provided. The other reason for providing a stack which could extract data from files is that it could be used for other things. For example, it could be used as part of an indexing process in the future, so that files could be searched based their type or content, so that you could search a database of metadata on files. Or even just as part of a 'Find' operation, the files could be searched as they were found.
I had played with was of extending the File information dialogue box which is available when a single file is selected. At the time, I had been using Audio MPEG data and tags as the data source, using my !AMInfo to provide greater information. I had tried to implement the information box as a major window with a pane to show related information (from other applications). The OptionsWindow style was used to toggle between the different information views. It seemed like a reasonable idea, but the window looked out of place with the rest of the Filer, and the work was abandoned.
I had already started work on alternate renderers for images. This was to be a registered (with Filer, because it would rely on the behaviour of the Filer itself) set of renderers that could produce different renditions of the files themselves. The purpose of this was to expand information into the thumbnail - for example, the image type might be included in the thumbnail view, or embedded image data might be included. Although this was just a toy as implemented, it might have been more useful if there was other metadata available for the files.
More generally, I had considered the replacement of Filer with another application written in C, or other high level language. The problem with that is that it has to reproduce the functionality of the existing Filer (in order to not alienate users), and still be manageable. That would be a lot of work, and it would not gain much except maintainability. Obviously being easier to maintain and extend is a big gain, it is only internal. It might mean that new features were easier to add, but they would have to be in line with the current style, so had to move slowly, which reduces the maintenance issues a little. If things are only changing slowly then there is less need to add new features.
Thomas Olsson's replacement Filer, !FilerPro was really good, but used Toolbox, which made it slower, and presented a big problem in terms of updatability. If there are applications using the Toolbox then you cannot upgrade the Toolbox easily, as the installer uses Toolbox as well. The installer could be reworked to not use the Toolbox itself, but that brings its own maintenance headaches. So replacing Filer with a Toolbox based system, although it would make development so much easier, would cause a whole world more problems.
I had previously considered complete replacements with different styles of Filer, in particular a Filer whose operation was scripted so that each viewer (if you had multiple, or each view as it changed location) could produce its own layout from a template, or directly from the data it is showing. This would allow more complex views, and ones that might not be scrollable in the same way - for example prioritising things that had been used before, or positioned manually, or even being entirely dynamic. Such an interface might have been more useful on a portable device, which I had been very keen to try to provide better support for.
The amount of work involved in that meant that it was less likely to come about. I had very briefly written a tree-based navigation Filer, to see how well it worked for simple use, and one thing that was obvious was that the file access was really bad on RISC OS, and that slowed things significantly. That is a whole area that needed a bit of a look at, but it was not changing any time soon, so the little test was abandoned.
As screen resolutions increase, text and icons become smaller for the same physical screen size. RISC OS has supported this in a limited way through the use of different 'eigenfactors' to change the relationship between OS screen units and pixels. The 'EX0 EY0' modes would become more common and would allow fonts to be rendered significantly better. The sprites used for icons had been updated as changing hardware allowed improved resolutions.
Originally sprites were one resolution, a 34x17 icon defined in a mode where
pixels were twice as high as they were wide. These sprites were stored in
!Sprites' files. These were later updated for square pixels,
with the name '
!Sprites22' being used for the files. This
allowed the square and rectangular styles to be distributed with
Later, for RISC OS 4, the depth of the icons was improved in the standard sprite set, from the standard 16 desktop colours to the full 256 colours. This did not involve a name change, but did change the style of the icons significantly. The change meant that sprites designed to match the older style (the 'A' Archimedes style) did not match the newer style.
Other styles had always been around, produced by enthusiasts, and had varying quality. Castle produced some significantly different designs as part of their releases, favouring photographic images over iconic images.
Until Select 2, using deep sprites (32,000 or 16 million colours) was not possible, because the WindowManager would not render them properly. This gave an opportunity to use higher quality icons. However, I preferred the icons to be iconic representations, rather then photographic. So whilst the ability to use the higher quality was available, I did not pursue using it - it was fine if others wanted to change the style, obviously.
The next increase would be to start using higher resolution square pixel
icons, known as '
EX0 EY0' and stored in the
!Sprites11' files. Select 4 completed the support for using
these, but we did not introduce a sprite set for it. Instead, sprites were
by this time being produced from DrawFile sources.
I had known, from Select 2 development that I did not want to have to spend time on designing icons in !Paint. I did not mind doing it, but it was tedious to generate good looking sprites for the application icon, filetype icon and (possibly) configuration icons, in different resolutions. Instead, I wanted to use a single source to generate all of the icons, with some small touch ups where the lower resolution icons needed it. As the thumbnailing was coming in, and would require larger Filer presentations, the small 34x34 icons would look a little silly beside the larger thumbnails.
The goal was that icons used in the Filer (and others) could be sourced from either the regular sprite pools, or generated on the fly from DrawFiles at the resolution desired. DrawFiles had already been created for many of the filetype sprites, and some of the core applications. Instead of designing any new icons from scratch in !Paint, they would be designed in !Draw along an alignment grid that made it easy to see how the image would appear when generated at different resolutions.
The components of the sprites were able to be easily reused, and retained their original design. The filetype sprite outline, for example, was easily reused as part of a template. The !Edit pen could be lifted from the application's DrawFile, cropped, and inserted into the filetype designs as required. So not only was the generation of the sprites for different resolutions far easier, but the style could be retained by reusing elements of the other icons.
I had begun on a module which would create sprites on-demand at different resolutions, but had not decided on a container format for the vectors. On the one hand, changing from using actual sprites files to using vectors was a great idea, and could be significantly more flexible. On the other, there was real world issue of how we actually handle the vectors. My earliest thought was to store the DrawFiles inside a Zip archive, named by the sprite they would represent. I didn't like this because it was a quite heavyweight solution.
Another solution I toyed with was using a new sprite type for 'DrawFile sprite'. The advantage would be that sprites and vectors could be mixed within the sprite file, and you would could load the file as normal. The disadvantage of this was that all the sprite operations that worked on real bitmaps would need to be reworked to handle it, !Paint would need some significant changes, and all third party applications would be put at risk by including data that they knew nothing about. It could get quite complicated.
It would be possible to use a directory of actual DrawFiles, named by the sprite they represented, but this would require much more disc access, and the DrawFiles were generally small so this might be quite wasteful. It would have the advantage that replacing icons would be much easier, though.
The solution I was tending towards was to use a DrawFile as the container
for multiple objects, using a custom object type to separate, and name,
the objects within it. The filename for the vector icons when loaded as
part of an '*IconSprites' operation (or similar) would be
V' suffix, eg '!SpritesV'. The default operation for a
*IconSprites would be to load the highest resolution icons
into the user pool, and load the vectors into a special pool, merging the
When a Wimp icon plot operation was required, the highest resolution icon would be used. Some new interfaces would be needed to manage application sprite pools so that they could benefit from the new icon types. I am not entirely sure how that would work, but it could be quite interesting. I had envisaged that the sprites would be defined with a design size, in a similar way that fonts had a design size which was used as a reference for scaling.
New Wimp validations would be created to allow scaling of icons. This would allow them to be shown larger, but without loss of detail in the case of the vectors. It would be nice if the scaling validation was able to be specified for different states. So if only a single scale was given it would be used on the sprite in all states. If two scales were given, the first would be used normally, and the second would be used when the icon was selected. If three scales were given, the first would be used for unscaled, the second when scaled, and the third when the mouse was over it (cumulative with the selection). I had considered that this degree of flexibility might lead to ugly interface designs, but I would rather allow the ability to be creative than force designers to use a very prescriptive interface.
There would be some issue of how you construct these icons, and initially I expected that there would be a simple tool which took a directory of DrawFiles and constructed a new DrawFile tagged appropriately. Later, though, I was hoping that we would be able to allow !Draw to edit the contained DrawFiles, in a similar sort of way that !DrawPlus had with its library functions.
Of course, if !Draw gained the ability to be invoked as an external editor by clients, it might be easy for other applications to use !Draw to edit their icons and return them. The selection system within the external edit protocol would work quite well for such uses.
Although there was still quite a way to go on the vector icons, the ground work had already been laid, and it was progressing nicely - if a little slowly. I did not expect that there would be much to dislike about changing to vectors - probably the criticism would come from the way that it was done, not that it was being done at all.