Discussion Paper on Window Manager Changes ========================================== 1. Issue -------- The RISC OS window system needs a few changes in order to become properly ‘themeable’: that is, be able to replace the standard set of sprites and other desktop items in a seamless and comprehensive manner. The following recommendations would fill the most obvious gaps in the Window Manager’s support for themes. Only those which seem relatively simple to fix have been listed. Other more ambitious changes may also be desirable (such as transparency effects, etc.), but they fall outside the scope of this document. 2. Constraints -------------- It would be preferable if changes to the RISC OS 5 Window Manager were API-compatible with those made to Select. Even where the success of such implementations may be debatable, the benefits of remaining consistent are obvious. 3. Desktop Elements ------------------- The areas where work is required are: - Handling of Window furniture - Handling of Window outline colours - Handling of 3D-style icons 4. Window Furniture ------------------- Issue: Currently, windows gaining the input focus have the colour of their title bar and tool icons changed by the Wimp. Toolsprite themes can allow this change to show up by using a simple mask. However, with modern high-colour graphics, it can be difficult to design appropriate sprites which accommodate the switch from light grey to cream while fitting in with a different colour scheme. Proposed solution: In addition to switching colours, the Wimp should use alternative sprites if present, prefixed by ‘f’ to indicate focus. Ideally, all toolsprites used by the Wimp should be able to be switched with ‘f’ equivalents, but some themes may choose only to supply variants for, e.g., the title bar sprites. 5. Window Outlines ------------------ Issue: Most windows have a window outline colour of &00 (black). This is fine for many themes, but if lighter colours are used for replacement toolsprites, black lines may look out of place. Proposed Solution: The colour used by the Wimp to draw window outlines should be set to a global value. This could be implemented as a switch in WimpVisualFlags (e.g. –WindowOutlineColour &DDEECC). Constraint: Rarely, some windows will set their outline colour to something other than &00 by altering the window block. The most common use for this is to make the border transparent by setting it to &FF. This behaviour should be preserved, so the Wimp should only overwrite the value in the window block if it is &00 (just as window backgrounds are only overwritten by sprite tiles if set to Wimp Colour 1). Additional Issue: On some occasions it would be desirable to have the window outline drawn *over* the toolsprites. If, for example, a theme employs sprites in the titlebar which have no hard edges drawn along their vertical sides (e.g. Richard Goodwin’s Clear theme), the resultant lack of a clear border to the window’s titlebar can look strange. A new switch in WimpVisualFlags (e.g. -WindowOutlineOverwrite) would allow more flexibility in ensuring that all windows have a drawn outline. 6. Icon Colours --------------- Issue: If a theme uses a window background texture much different in colour to the default Wimp Colour 1, then the grey 3D-style buttons drawn by the Wimp will be out of place. Proposed Solution: Buttons with R-type borders should be drawn using global colour values set by a command equivalent to Select’s IconBorder. Although this API is not completely ideal, the syntax should be followed to ensure compatibility. Not all of IconBorder need be implemented (i.e., the blending and curved borders): just the switches controlling the colour of the button face and borders. The relevant switches in Select’s IconBorder are: -special Use special colours -specialactionfg &RRGGBB Set Action Button foreground -specialdefaultfg &RRGGBB Set Default Button foreground -specialinfofg &RRGGBB Set Information Field foreground* -specialaction &RRGGBB Set Action Button background -specialdefault &RRGGBB Set Default Button background -specialinfo &RRGGBB Set Information Field background* -colourgroup &RRGGBB Set Frame colour * Not implemented in Select (perhaps due to constraint discussed below), although some other attributes of ‘sunken’ fields are configurable. Where specified separately, the background colour sets the ‘face’ of the slabbed icon, and the corresponding highlight/shade is calculated from this. The foreground colour controls the text. Constraint: Altering the face colour of most R-type icons, such as Action Buttons, Default Buttons and Frames, should present no serious compatibility issues. However, Information Fields (R2) present a slight obstacle, in that many programs use these icons to display user-changeable colours, either from the default 16-colour Desktop set using the icon flags or a 24-bit value using the ‘C’ validation string. A suitable solution would be for the Wimp to use the global colour value only if (a) the ‘C’ validation string is unused, and (b) the colour value set by the icon flags is Wimp Colour 1. Chris Wraight 21 May 2007