How to create a modern desktop theme - RISC OS News, Software and Information

How to create a modern desktop theme

Published: 4th Oct 2006, 01:04:34GMT Source: drobe.co.uk
By Chris Wraight

Page 1 of 1

More to life than drab 16 colours of 1994 [Updated]

In a precis of RISC OS for OSNews, Chris Wraight stunned us with a set of previously unseen toolsprites in his article's screenshots. Here he explains how RISC OS can be given a more modern gloss, and how he created the stylish desktop theme - which is now available for download from drobe.co.uk.

New looks for RISC OS
The RISC OS desktop, with all its many virtues, has been stuck with more or less the same set of widgets and furniture for several years now. There's nothing intrinsically wrong with Acorn's designs: at the time of the release of NewLook - which set the basic style still used today - the RISC OS 3 user interface compared respectably with the Windows and Mac desktops of the era. However, things have moved on, and the standard RISC OS desktop looks somewhat tired in comparison to contemporary alternatives. The screenshot below shows how things appear for most users:

Dull salt and pepper grey design from the 1990s

Most of the pictured elements here date from a time when RISC OS desktops used 16 colours, and as a result rely on an eight-colour grey-scale to achieve the 3D effect of raised buttons and window tools. Modern systems generally run 8-, 16- or 32-bit displays, so there's plenty of scope to improve on this rather basic setup. Indeed, there's been some progress in recent years: both RISC OS 4 and 5 make use of 256-colour icons in Filer displays, and newer versions of RISC OS Select allow some OS gadgets to be re-coloured and graduated. However, in my view, which is not universally shared judging by some criticism of Select's cosmetic enhancements on the web, these have been somewhat piecemeal: even the most modern desktops look dated compared to alternatives.

However, there are things you can do to improve the situation. The purpose of this article is (a) to demonstrate the extent to which it is possible to tart-up the RISC OS desktop, and (b) to outline certain simple improvements the OS developers could take which would enable more comprehensive 'skinning' to take place.

The elements of the desktop
If you take a look at the first screenshot again, you'll see that the graphical elements of the various windows fall into three rough categories:

Desktop icons, used to represent objects such as disk drives and files;
Window furniture: tool gadgets, scrollbars, background textures;
Gadgets used in windows, such as action buttons, slider bars, frames, etc.

The good news is that you can completely replace the first two element types with your own graphics, giving the desktop a substantially different appearance. Window gadgets are slightly more complicated: some can be replaced if they're simple sprites, such as the option and radio buttons, but others rely on the OS to be redrawn and are less configurable - such as action buttons, frames and information fields. Under Select, this situation is improved somewhat, but is still not entirely ideal, as we'll see later.

Using your own sprite files
Right, let's make a start. The first thing to do is to make copies of the files the OS uses. There are two spritefiles you're after: a 'Tools' file which controls the window furniture minus the background textures, and a 'Sprites' file which is huge and defines the graphics for everything else, including textures, standard file icons, simple sprite gadgets, and other bits and bobs.

You can do this by going to the Apps folder on the iconbar and choosing 'Open $' from its iconbar menu. This will open a window with three or more directories. Open the 'Resources' directory, and from within that open the 'Wimp' directory. Inside, there should be the two files you need to make copies of: 'Sprites22' (or 'Sprites' if you're working in low-res) and 'Tools'. Save a copy of each somewhere safe.

Now have a look through your copies and see how they're designed. There are a lot of sprites to look at, but bear in mind that you won't have to redefine all of them to make substantial changes to the OS. If you only work in high resolution, then you need only edit sprites with the '22' suffix, and unless you're really keen there's no need to edit all the sprites used for the various files RISC OS knows about.

One thing to observe is the colour depth of the sprites. If you're using a flavour of RISC OS 4, including Select, you'll notice that most are either 16-colour or fixed-palette 256-colour sprites. On RISC OS 5, most of the sprites are optimised-palette 256-colour sprites. However, you're not constrained to use the same colour depth with your replacements. All modern versions of RISC OS can cope with high-colour icons and tools, so in my view there's no excuse for using 16-colour sprites any longer.

In my experience, sprites used as Tools can cause problems if they have their own palette, so I would recommend designing these as 16-bit sprites, which grants you 32 thousand colours, without a palette. All other graphics can use definable-palette 256-colour sprites, which save some memory. An exception to this is the window and menu background textures: these come in several varieties to cater for different colour depth displays, so you should retain the same colour model in each when designing replacements.

Another issue is transparency. On Select, you can define sprites with an Alpha channel. This enables you to create variable degrees of opacity, rather than the simple 100% transparent mask used by earlier versions of RISC OS 4 and current versions of RISC OS 5. This is a great feature, especially for designing sprites with irregular outlines, such as application icons, as the edges can now be anti-aliased for any colour backdrop, not just the normal light-grey. However, the lack of a similar facility on the Iyonix means that you shouldn't use it unless you want your snazzy new icons to be confined to machines with Select only.

Once you've rummaged through the files and worked out which sprites go where, replacing the default set is simply a matter of editing those sprites you wish to change, usually keeping the dimensions the same, and saving the new files somewhere safe. A description of how the different sprites fit together is described in the RISC OS Programmers Reference Manual, in particular volume 3 page 25 onwards.

Each sprite component in a window's furniture is given a name which corresponds to its location around a window. bicon and pbicon are the back icon and the pushed in back icon. cicon is the close icon. tbarlcap/ptbarlcap is the left hand title bar end cap. tbarmidt/ptbarmidt is the middle top half of the title bar. tbarmidb/ptbarmidb is the middle bottom half of the title bar. tbarrcap/ptbarrcap is the title bar right hand end cap. ticon, ticon1 are the two toggle icon states. uicon/puicon is the scroll bar up arrow. dicon/pdicon is the scroll bar down arrow. vwelltcap is the vertical scroll well top end cap. vwellt is the vertical scroll well top section. vbart/pvbart is the vertical scroll bar top end cap. vbarmid/pvbarmid is the vertical scroll bar middle section. vbarb/pvbarb is the vertical scroll bar bottom end cap. vwellb is the vertical scroll well bottom section. vwellbcap is the vertical scroll well bottom end cap. sicon/psicon is the Adjust Size icon. blicon is the replacement Adjust Size icon when it is not required. licon/plicon is the scroll bar left arrow. hwelllcap is the horizontal scroll well left end cap. hwelll is the horizontal scroll well left section. hbarl/phbarl is the horizontal scroll bar left end cap. hbarmid/phbarmid is the horizontal scroll bar middle section. hbarr/phbarr is the horizontal scroll bar right end cap. hwellr is the horizontal scroll well right section. hwellrcap is the horizontal scroll well right end cap. ricon/pricon is the scroll bar right arrow.

You can of course use Paint to edit these two files, but I'd recommend a recent version of ArtWorks for any serious work - it really is a great tool for creating bitmaps as well as vector art. Once you're happy with your new sprites, load them over the default set by creating an Obey file in the same directory as your doctored sprites with the following two lines:

IconSprites <Obey$Dir>.Sprites

ToolSprites <Obey$Dir>.Tools

If you double-click on this file, the Window Manager should replace its original set of graphics with your new ones. Note that it might take a few moments for this process to complete on slower machines, and you may have to force a redraw of the Desktop to actually see the changes - press F12 followed by Enter to do this.

Once you've got a set of graphics you're happy with, you can opt to use them automatically at start-up. Do this by putting your edited spritefiles in an application directory called, say, !MySkin. Then rename your Obey file to '!Boot' and place inside the application directory, along with a !Run file with the same contents. If you put !MySkin anywhere where it will be seen during the boot-up process (for example, in !Boot.Resources or preferably using the Boot Run tool in !Configure), then your shiny new sprites will be used every time you start the Desktop. Once again, be aware that switching sets over, for instance on a mode change, can take a bit of time on older machines - there are a lot of sprites to get through.

Difficulties and annoyances
To illustrate what you can do, in true Blue Peter style, below is a link to a set I made earlier called 'Chrome'. This is not a complete replacement of the standard icon sets by any means: the main changes are to the window tools, background textures and some gadgets. The sprites are mostly high-colour, so they may not work on all OS versions although they've been tested on Select 3 and RISC OS 5. The screenshot below illustrates the changes made: the window tools are graduated, the background textures are more subdued, the radio and option gadgets look different.

Easier on the eyes

However, you'll also notice some idiosyncrasies. The most glaring is that the Chrome sprites and textures are a blue-grey colour, while the action buttons, frames and other gadgets drawn directly by the OS are still in the drab uniform grey we were trying to replace. On RISC OS 5 and non-Select RISC OS 4, there's nothing you can do about this: there's no option to replace the colours used universally by the Desktop to draw its gadgets. On recent versions of Select, things are bit better: you can specify colours for the 'slabbed' buttons (R5 and R6 border types) and for frames (R4), also adding a graduated effect and rounded edges if you wish. These settings are controlled from the global Configure application, and this screenshot shows what you can do with a bit of fiddling:

Action buttons falling in line with the desktop theme

This looks a lot better, but there's still some rogue grey around. On Select 3i3, which is the version I have, sunken fields (R2 type borders) and slabbed areas (R1 type borders) seem to be exempt from this colour alteration facility. My guess is that, as these gadgets are commonly used for displaying user-defined colour fields, allowing their backgrounds to be set to a global colour value would prevent some colour selection dialogue boxes from working. If true, it seems a bit odd to me - I outline a potential workaround below.

Suggested Select icon settings to use with Chris's sprites
- Rounded button edges, group edges, sounded writeable icons, and rounded information fields switched off.
- Special colour schemes enabled, special colours as a tint switched off.
- Action button colour: red 86.7% green 86.7% blue 100.0%
- Default button colour: red 73.3% green 73.3% blue 100.0%
- Groups colour: red 60.0% green 60.0% blue 60.0%
- Black text and rim colour
- Blend applied to button icons, blend applied to information fields, rim applied to button icons (optional), thin borders switched off, apply colours to sprite icons switched off, draw groupings as outlines switch on.

To add to this problem of non-user-definable gadget colours, there's the issue of input focus. In the first screenshot you'll notice that the middle window has the input focus. In fact, it does so in the subsequent shots too; only, in these instances, the focus effect is invisible. This is because of a curious bodge Acorn adopted when replacing the RISC OS 2 window furniture with the RISC OS 3 set: instead of the Desktop replacing the standard titlebar sprites with a different set when a window gains the input focus, current versions of the OS merely change the underlying colour of the titlebar from light-grey to cream.

This shows up on the Acorn-era window furniture because the default sprites have transparent pixels which let the colour underneath show. Of course, there's nothing to stop your replacement set having similar transparent patches. However, this will only work if your carefully-chosen new colour scheme looks good with light-grey and cream areas in the title bar. I don't think it works with my changes, so I've reluctantly opted to lose the visible input focus in my new scheme. Which is a bit of a pain, as now I can't see at a glance which windows are trapping keypresses. Again, this could easily be addressed - see below.

And one final moan: even with the Select improvements, actually putting together a coherent replacement theme for the Desktop is a real pain. There's no way to save different colour settings from Configure and swap between them unless you dig out the settings file from within !Boot. At present, anyone with Select wishing to replicate the Chrome theme would have to manually fiddle with the colour values for the gadgets from !Configure to get the same results. What would be ideal is a single Configure plugin which would bring together all the various configurable display elements we've been discussing, plus related features such as the Desktop font and the Pinboard, allowing all these settings to be saved in a single 'theme' file. Such files could then be posted on the Internet and exchanged, allowing creative types to significantly improve RISC OS's appearance - and perhaps, even slightly, its perception in the outside world.

As it happens, there is an excellent third-party theme manager application available, originally developed by Richard Goodwin. This appears as a Configure plugin, and brings together a variety of aspects of the desktop appearance including sounds. Regrettably, the current version doesn't seem to work on Select, and as yet doesn't offer support for extra features such as button shading. With any luck, this situation might change. However, one might think that such functionality ought to be provided by the OS: ROL or Castle could do worse than investigating bringing Richard's theme manager or a similar application into future releases of RISC OS.

Some suggestions to our OS developers
Enough gripes - what about some positive suggestions? Drawing on the above, my wish-list of key improvements would be as follows:

Create new toolsprites types for window titlebars for use with the input focus, and get the OS to switch between these automatically when the focus is gained or lost.
(RISC OS 5) Allow gadgets with 3D borders to have their colours redefined. This would not have to be as elaborate as Select's implementation: just setting global values for 3D Highlight, 3D Face, 3D Shade, 3D Gutter (Default buttons) and 3D Frame Shade (for R4 borders) would enable the RISC OS gadgets to fit seamlessly with even radical departures from the original grey colour scheme.
(Select) Allow all desktop gadgets, including slabbed areas (R1) and sunken fields (R2) to have their face set to a global colour value. To avoid corrupting colour selection dialogue boxes, perhaps one could adopt the rule that R2 fields will have their colour set to the global value unless the 'C' option in the validation string is set (indicating it's probably being set to a non-standard colour) or the icon's colour flags are anything other than Wimp Colour 1. This would alleviate the worst of the (mild) problems, and allow developers to easily avoid clashes when designing their templates.
Review the design of the Configure applications which deal with the Desktop's visual appearance to bring together all the relevant sections more rationally, and allow the settings to be saved into a file. Perhaps take a leaf from the very sensible way Windows does it, shock horror.

There are no doubt other changes that could be made which would further enable comprehensive skinning of RISC OS, but in my view these are the most important, and would be quick wins. Let's see if anything comes of it. In the meantime, however, I hope that this article is helpful for anyone wishing to fiddle with the settings as they are, and that it prompts some more creative themes to lift RISC OS from the 1990s and into the present.

Two articles about RISC OS made it through to the finals in the OSNews feature writing competition. Chris Wraight and Gavin Wraith both won one year subscriptions as prizes.

Update at 21:19 9/10/2006
Chris has provided a new set of sprites that will work for Iyonix users. Download the complete set from the link below.

Links
Download Chris's toolsprites and iconsprites

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

Eddie (+2.0) 4/10/06 6:43AM	Excellent article - well done Chris.
druck (+2.0) 4/10/06 9:43AM	Very sensible suggestions, proper integrated theme management would have avoided the cosmetic appearance jibes made against Select. I'm sure this is the type of feature that will be one of the first to appear when(if) the ROOL make Window Manager source available.
GavinWraith (+3.0) 4/10/06 10:00AM	Useful article, Chris, and congratulations on your OSNews article from your colleague! On the topic of themes, I think it is worth mentioning Richard Hallas's article "Iconix: A New Face for RISC OS 5" in FRU 11, about how he went about designing the RISC OS 5 icons. Very interesting to see the inner workings of a designer.
GavinWraith (+1.0) 4/10/06 10:13AM	Concerning Richard Goodwin's Theme Manager software on the Iconbar site: there is a little application called MouseSprites that changes the pointer when it is moved over a window's toolicons to an appropriate shape for the tool. Be warned that in its current form it slows down the desktop because it responds to all null events. I have a slightly amended version that does not slow the desktop down. I have emailed the author but have not had a reply. If Drobe wants to host my version, it has but to ask.
SimonC (+2.0) 4/10/06 10:24AM	Would a semi-transparent title bar sprite work with Select? Having done a little playing around on Select to make the sprites I have stuck on my pinboard blend in I can say that it is one thing that whilst purely cosmetic makes a great deal of difference to a casual perception of a RISC OS desktop. Another (which AFAIK can't be done on any version) would be make the text below pinboard items stand out a bit better. A small shadow beneath it on the Linux machine I use at work means it's viewable whatever the background colour.
lym (+2.0) 4/10/06 11:30AM	In reply to GavinWraith Thanks - congrats to you too To be honest, I have very little idea of how the Iyonix desktop looks (screenshots can only tell you so much), so Richard may have made significant improvements. I certainly think his icon set looks snazzy. I'm guessing, however, that it's still stuck with granite grey for the windows, and that irregular-shaped icons can't benefit from the background blending and alpha channel allows. SimonC is right: a small change, but it makes a big difference.
hEgelia (+2.0) 4/10/06 3:19PM	An interesting article. Somehow I keep changing the appearance of my desktop from time to time and have been doing so since Acorn's NewLook came out! At the moment it features a mix of KDE, RO5 and OS X icons... While RO5's default look is good, RO4's look has remained stuck in the nineties and, like the article rightly points out, it does not make use of varying palettes or higher colour modes. Surely most of us work with 15-bit ( 32.768 ) colours or more? While uniformity can be a good thing, RO4's icons lack distinction. For an improved variation on those icons, check out: http://www.somascape.org/riscos/misc/4icons.html Ofcourse, I've immediately downloaded Chris' chromic look sprites which look quite good and much better than the default RO4 tools and gadgets. I do have one point of critique though; normally a window with input focus has a highlighted title bar, but apparently not so with the chromic tools set. Perhaps I need to reboot with them? Anyway, the suggestions Chris made for the developers of RO are quite interesting, of which I found the first and the last most practical for everyday use. Btw, a tip to create variable 256c palette icons - use InterGif to create optimum palettes from 16 or 24-bit images.
druck 4/10/06 3:42PM	The issue with input focus highlighting is explained in the artical next to the green box.
hEgelia 4/10/06 4:37PM	*In reply to druck:* Indeed, thanks for pointing that out. Feel a bit stupid I missed it earlier, also because I found Chris' solution a good idea. Too bad this issue wasn't 'fixed' in RO4, but I imagine they weren't thinking about this since they weren't intent on replacing the toolsprites.
RichardHallas (+4.0) 4/10/06 5:04PM	The article of mine that Gavin Wraith refers to above can actually be found online. I put a copy on some personal Web space to show to someone ages ago, and forgot to remove it afterwards, so it isn't part of the official FRU Online site or linked from anywhere else. Anyway, I might as well leave it there for the time being in case anyone wants to read it. It's pretty long, but it does go into a large amount of detail about how I created the RISC OS 5 icon set, and some of the associated challenges, goals and underlying ideas. Here's the link: http://home.freeuk.com/richardhallas/iyonix/ *In reply to lym:* "I'm guessing, however, that it's still stuck with granite grey for the windows" Well, the Iyonix window-background texture is actually 'paper', and it's strictly not grey. (As the above-linked article explains, the paper texture actually uses lots of pale colour-noise to give an impression of 'warmth', rather than the starkness of pure grey-scale pixels.) But the overall effect is of a pale grey of the usual Wimp Grey 1 intensity, yes. (I do think that my texture works a lot better than the RO4 marble effect though.) "and that irregular-shaped icons can't benefit from the background blending and alpha channel allows." The RISC OS 5 icons were designed from the outset with alpha blending in mind, and the fact that they don't use that feature at present is simply due to the fact that RISC OS 5 currently doesn't support it. If that support were forthcoming at some future point, it should be relatively easy to regenerate the RO5 icons in alpha-blended versions, which feature 'real' shadows etc., and this is something that I'd very much like to do. It's a feature that I've wanted on the Iyonix ever since its release. The thing to bear in mind is that RISC OS 5's feature set is very similar to that of RISC OS 4.0x, and so there are things that it can't do that Select /can/ do. It's always struck me as rather ironic that RO5, which doesn't support alpha-blended icons, has an icon set that would benefit hugely from that feature, and could really make good use of it, whereas RO Select does support alpha-channel sprites but doesn't have a suitable set of sprites to take advantage of the feature. The only novel icon-related feature of RO5, compared with RO4, is the support for high-definition icons (in EX=0, EY=0 screen modes). RO4 actually supports this feature but has no icons to take advantage of it; my RO5 set includes a full complement of high-definition icons. RO5 also supports high-definition window tools (and, again, includes a set), whereas RO4 doesn't support them at all. What I'd personally love to see in future is a universal adoption of my RO5 sprites for future versions of RISC OS, suitably updated to take advantage of alpha-blending. I'd be more than happy to do the necessary work to generate the new set. Perhaps this is something that could happen via RISC OS Open (but that's just speculation; no-one has approached me about it yet, and it would have to be done with Castle's agreement). I'm personally not a fan of rounded and/or graduated-filled button icons. I'm not against them in principle, but I've yet to see any under RISC OS that look anything other than appalling. What I'd like to see is some way for more sophisticated button icons to be drawn out of alpha-blended graphical components. The current shading options in Select just don't cut it, and the rounded-edged buttons, which lack even basic anti-aliasing, look dreadfully amateurish.
lym (+3.0) 4/10/06 5:38PM	*In reply to RichardHallas:* Very interesting article: wish I'd read it before writing mine! The problem with the current set-up, on both RO4 and RO5, is that any colour scheme will have to be close to grey to avoid colour clashes with major gadgets, such as action buttons. Your scheme is considerably warmer, and very nice. But it would be good to be able to depart radically from the greyness if wanted and keep the desktop looking consistent. Preferences are obviously very subjective. I do like your file icons very much, and they would be wonderful with an alpha channel. I think I slightly prefer RO4's uniform 'jigsaw' approach to the configure applications, and I'm not sure I'm fully sold on your drive icons. But it's great to have the choice. I presume you're not able to currently distribute your iconset independently of the OS? I agree about the rounded icons: without antialiasing they look pretty poor. But I think the graduated faces look good when used with restraint. Finally, I'd noticed the '11Sprites' files in things like NetSurf - I assume these are the high-definition sprites you refer to. How are these currently used? Can RO5 display file icons at double size?
RichardHallas (+3.0) 4/10/06 6:59PM	*In reply to lyn:* I think I slightly prefer RO4's uniform 'jigsaw' approach to the configure applications, and I'm not sure I'm fully sold on your drive icons. Interesting that you should mention these two items in particular, because... 1. I was specifically asked to drop the jigsaw-puzzle outlines and do the Configure icons without borders, in the manner you see them. Though, whilst I quite liked the puzzle-piece shapes, I do personally rather like the style without them. As jigsaw pieces they do look somewhat regimented. I don't really have strong feelings either way; my point is just that this was something that Castle specifically asked for. 2. The drive icons caused a great deal of trouble - more than any other element, as I probably mentioned in my long article. That article does show a number of alternatives that were done, and I personally liked the 'bare hard drive' icons that I did first. (A few other people expressed a preference for these too - particularly the icon that looks a bit like a door bell!) Castle insisted that they looked too technical, though (people aren't expected to know what the inside of a hard drive looks like), and asked me to do something simpler. The icons we ended up with were the least objectional to the largest number of people, apparently, but I can't really claim to like them very much myself. "I presume you're not able to currently distribute your iconset independently of the OS?" Sadly not; they're the property of Castle. However, for anyone who owns an Iyonix, it's not difficult to copy them across to a RISC OS 4 machine and use them on that; there's a complete set of icons in the RO5 set, including ones that only Select actually uses. You just copy the !+Resource application over from inside !Boot (somewhere in PreDesk, I think) and delete the unwanted modules inside it, leaving just the two that define (a) the Wimp sprite pool and (b) the window tools. "Finally, I'd noticed the '11Sprites' files in things like NetSurf - I assume these are the high-definition sprites you refer to. How are these currently used? Can RO5 display file icons at double size?" It certainly can. Just edit the mode definition string for the current screen mode (availble from the Display Manager's icon bar menu) so that the EX and EY parameters are zero and click OK. You'll end up in a new screen mode, the same size and number of colours as before, but with big, double-detail graphics. (Obviously, you can do this for any mode; just edit the mode def string as appropriate.) It's a shame that there isn't a neater interface to this.
GavinWraith (+3.0) 4/10/06 8:20PM	Chris Wraight's final moan raises a very interesting topic. On occasions I have tried personalizing the toolsprites, and just using !Paint it is a tedious and difficult exercise. No doubt with ArtWorks it is a lot easier, but I suspect that ArtWorks only works on a sprite by sprite basis. No, what is needed are "scriptable" tools for creating sets of icons; something that lets you work at a much higher level of abstraction and under automatic control. I look forward to the release of the RO5 sources of !Paint and the other applications, because I want to make them all scriptable. I recently sent an email to ROOL on this topic. "Configurability" means user control of constants, strings and numbers, in an application. "Scriptability" means user control of key functions, such as event handlers, as well. My roadmap is to construct a shared Lua library with which !Paint, !Draw, !Edit et al could be linked, so that they could be controlled not just by mouse and keyboard input but by scripts as well. Any kind of application for creating sets of icons sharing a common theme would have to go along some such route. Anyway, I have to be careful to catch my hare before I skin it.
nx (+2.0) 4/10/06 8:37PM	This is a very well written and informative articele. It is great to see users taking the appearance of RISC OS very seriously. Richard Hallas: I've just read your articele too - very impressive. Thanks nx
martin (+6.2) 4/10/06 9:46PM	I seem to recall that ROL were toying with the idea of taking all of the current desktop sprites and window furnature and making it vector graphic based. Possibly this was to be !Draw based although I half remember (from one of the shows last year) some intense discussion about involving Artworks. To involve ArtWorks would require a module that rendered the built in vector graphics - but it was thought that MW might be willing to help with this (based on the existing free AW viewer). You'd possibly need ArtWorks itself to design a personalised skin for the desktop. The big payoff was to be a desktop with one set of vector based graphics that adjusted to the resolution and colour depths in use more fluidly than having several sets of increasingly memory hungey sprites. (And more of them with each future extension of the OS) The vector graphics based WIMP would also be, alegedly, more future proof. So, from this point of view, ROL were/are probably reluctant to invest time in tarting up the existing sprite based system which they seemed (at the time) to be viewing as a dead end part of the OS. I don't know if any serious developement of this idea has yet taken place by ROL or anyone else though. Perhaps someone who knows more about the practicalities of all of this than I might like to comment.
flibble (+2.0) 4/10/06 11:37PM	I really ought to try and find these 2 themes again, if anyone is interested in a copy. Smokey Blue, based upon a GTK2 theme http://marutan.net/pics/screen.png A flat white theme, I tried to follow the style of Spriteman's toolsprites accross the iconsprites. http://www.spod.org/~peter/theming.PNG
flypig (+2.0) 4/10/06 11:59PM	A great article; thanks Chris & drobe! I'm also waiting in the hope that alpha channels will be introduced into RISC OS 5. This is one of the features I miss most from Select (I think it's also one of those features that would work best if it were available on all machines, so that sprites with alpha channels could be used for applications). Having said that, I do think what Martin says about vector graphics is the way forward. RISC OS is in an ideal position to make the most of this kind of technology. It's interesting to compare the article with the apple guidelines (also recently posted on OSnews.com): [Link: developer.apple.com] And I always find the following site fascinating to compare against other systems: http://www.guidebookgallery.org/icons
RichardHallas (+2.0) 5/10/06 10:12AM	*In reply to martin:* Unfortunately I'm not in a position to make any useful comment about RISCOS Ltd's supposed vector icons idea because I know nothing of it myself, and have not been involved with it in any way. I've heard the odd rumour about this idea, as have others, but I know nothing concrete. However, what I can say on this subject is that, if it were to happen, the RISC OS 5 icons would be in an ideal position to take advantage of it, because they were all designed in ArtWorks from the outset. It would be simplicity itself to derive a new set of vector-based OS icons from my current ArtWorks sources; and alpha-blending would also presumably work, too. This would also be a far more sensible and realistic proposition than starting from scratch with a new vector set based on, say, the existing RISC OS 4 icons or any other theme. Believe me when I say that the creation of a set of consistent, good-looking, carefully thought out desktop icons is not a trivial process! Even with the advantages of ArtWorks and the benefits it brings (e.g. the ability to use layers to copy and overlay elements and create consistency between icons), the creation of the RO5 icon set took a very considerable amount of time and effort. Obviously it would have taken a lot /more/ time and effort if I'd used a bitmap editor rather than a vector drawing package but, even so, quite a lot of bitmap post-editing was required to create the TV-resolution versions and other things. These tall-pixel sprites do present a bit of a problem with respect to vector rendering, but hopefully not an insurmountable one. *In reply to GavinWraith:* The window tools proved to be pretty demanding and required a lot of work, but are also vector-based and were created in ArtWorks, though they do make use of bitmaps to create the various textures. I agree in principle that it should be possible to make them scriptable in some way, though in reality the way they're plotted by the Wimp is one of the major problems that would need to be overcome. People have complained and disagreed about the window tools more than any other aspect of the RISC OS 5 appearance, but leaving aside the issue of whether you like my designs or not, it must be recognised that the designer is very much restricted in terms of what he can do by limitations and shortcomings inherent to the Wimp's handling of window furniture. To improve the situation in any genuinely useful way would require a complete rewrite of this part of the Wimp itself. You can get around some of the issues by some fudging (e.g. the need for there to be a pixel border separating all tools can be circumvented, but only by making ugly compromises in other ways, such as having open-ended title bars that don't look finished off properly - as in those Mac OS X rip-off window tools, which I personally dislike very much). There's plenty of other things that you just can't do, though, like using lots of colours to improve shading etc., and there are bugs that you have to work around too, which cause problems and compromises of their own. What I'd like to see is a fully customisable way of creating window tools in which the symbols for the tools could be defined independently of the backgrounds, and the backgrounds themselves could be more flexible. If the window tools were to become vector-based, then it should certainly be easier to achieve this.
GavinWraith (+2.0) 5/10/06 11:23AM	One of the features of the Mac OS GUI that really stands out (sorry for the pun) is drop-shadows for menus. They help to give a more 3D effect. Not having a Mac myself, I do not know how successfully they work on heterogeneous backgrounds. Theoretically an object's shadow should depend on the relative height between the object and the local background. That leads to complications in processing that maybe outweigh the advantages of the effect. Perhaps having a semitransparent shadow of constant width is an acceptable compromise.
nx (+3.0) 5/10/06 12:56PM	Martin makes reference to vector graphic being a way forward as ROL has mentioned it in the past, but aren't we missing something here. Wouldn't the next logical step be creating true 3d models in software such as 3D MAX (on PC) or Top Model on RISC OS. That would truly be a cutting edge desktop look and feel. It would allow for 'icons' to be modified on the fly too using 3D routines that alter the object, persepective, angle, lighting and animation etc... It might be a long way off for RISC OS, but ideally thats what I would like to see nx
GavinWraith (+3.0) 5/10/06 3:24PM	There is a lot more to 3D than just perspective drawing. Illumination, shadows, etc mean that components of a picture interact with each other in a way that requires much more intensive processing than 2D. This means that it is a question of balancing the effects you would like to have against the limitations of the equipment, and making compromises. Personally, I see the future of GUIs not in 3D realism but in the accumulated ideas of art history. I include cartoons, morphing, pointillism, abstract art etc. That certainly seems to be the way that games are going.
nx (+2.0) 5/10/06 3:42PM	I agree with most of your comments - certainly, more processing more would be required for the full blown. As for the future of the GUI based on cartoons, morphiong rather than photo-realism - you may well be correct. But 3D models would not stop designers from implementing any form of 'theme' for the desktop. It would merely make it far more impressive to the end user. Having a proper 3D desktop would allow for a fully interactive experience. It would be akin to the change from a 2d games to 3D games back in the 90's. nx
druck (+4.0) 5/10/06 3:59PM	But remember the desktop isn't a 3D game, its a representation of... a real desktop. i.e. 2D sheets of paper stacked on top of each other. Introducing a load of 3D and/or transparency effects will make it distracting and less productive. No one has yet come up with a truely workable 3D metaphore for driving standard computer tasks, and if you want to see what a complete pigs ear can be made of it, look no further than Microsoft's Vista 3D Aero interface, and the trail of vomit left by beta testers.
flypig (+1.0) 5/10/06 4:58PM	There have been lots of real attempts to move the desktop to 3D; personally I think some of them have been quite good. I'm not sure if Vista even registers compared to these. For example BumpTop: http://honeybrown.ca/Pubs/BumpTop.html which looks like it may have been inspired by an Apple idea: [Link: www.cs.columbia.edu] Sun's Project Looking Glass: http://www.sun.com/software/looking_glass/ Even Acorn had a prototype 3D desktop environment on a Clan CD (released at Acorn World in 1997 if I recall correctly), but I can't find any links to it. Does anyone know what happened to this?
Eddie (+1.0) 5/10/06 7:39PM	Thanks for the interesting discusion above - very good. Just had a look at the !Chrome sprites in more detail on my Iyo and 'HiSprites' just gives me an error 'Unrecognised Sprite Data'. 'HiTools' opens OK. Even Artworks doesn't like 'HiSprites'. Mmmm....
GavinWraith 5/10/06 7:51PM	I do not think I would want the "desktop" of my computer to resemble my furniture desktop - what a mess. I would like it to be better. In the same way, I think it is Genuine Stupidity for Artificial Intelligence to be trying to mimic what humans can do. What they cannot do is interesting too.
lym 5/10/06 8:47PM	To Eddie: Sorry about that - I was worried they wouldn't work quite right on an Iyonix, as they were all drawn on a RO4 computer - one of the frustrations of this stupid OS split. I'll have a look at the set here and check there is an alpha-channel sprite in there by mistake, which may the reason your Iyonix won't load them.
JGZimmerle (+1.0) 5/10/06 9:36PM	With modern graphics cards, surely the resources for 3D desktops are already there? I just don't see why we should stick with 2D vector graphics, when we could directly move to 3D. The rest of the computing world is doing just that right now. MacOS has done it a few years back and now Linux and Windows are following. As usual the Windows version seems to be the worst design, but just imagine how cool it would be to bring RISC OS' effecient and user-friendly GUI to the third dimension.
GavinWraith 5/10/06 10:23PM	Just google "wavelet nVIDIA" to get an idea of what is locked up in the Iyonix, in a form as yet unexploitable, alas.
JGZimmerle 5/10/06 10:47PM	Can't you just give a web-address? Not everyone likes Google.
Use the forum for more comments on this article