Commit 530acd4a authored by Neil Turton's avatar Neil Turton
Browse files

Import from cleaned 360 CD

parents
hdr/** gitlab-language=armasm linguist-language=armasm linguist-detectable=true
s/** gitlab-language=armasm linguist-language=armasm linguist-detectable=true
*,ffb gitlab-language=bbcbasic linguist-language=bbcbasic linguist-detectable=true
**/c/** gitlab-language=c linguist-language=c linguist-detectable=true
Neil, and others write about keys in dboxes:
>Both the Mac System and Windows 3 use TAB and shift-TAB (in addition to the
>cursor keys) to move between fields (and not only writable fields in
>Windows!). The logic is that the fields are a matrix or grid of objects,
>much like the cells of a spreadsheet, and that the TAB key moves the caret
>to the next logical cell, from left to right; top to bottom.
Well, the next thing that's going to happen is that he's going to want it
in !Configure and all the other applications so ...
WIMP 2.92 (on my machine and soon in RISC OS :-) provides the following new
validation string command for icons:
The K (Keys) validation string command:
---------------------------------------
**NOTE**: Next and previous in the following description is determined by
the icon number in the window definition.
From WIMP 2.92 onwards the following command is accepted in validation
strings of icons:
K followed by any or all of R,A,T,D
IF KR is present in the icon's validation string and the icon is
not the last icon in the window, pressing <Return> in the icon will move the
caret to the beginning of the next writable icon in the window. If the icon
is the last writable icon in the window the <Return> (Code 13) will be
passed to the application as in WIMP 2.00.
IF KA is present in the icon's validation string, pressing the up or
down arrow keys will move the caret to the previous or next writable icon in
the window, retaining the same position in the string. Pressing up in the
first writable icon in a window will move the caret to the last
writable icon, and pressing down in the last icon will move the caret to the
first icon.
IF KT is present in the icon's validation string, pressing TAB in
the icon will move the caret to the beginning of the next writable icon in
the window. Pressing Shift+TAB will move the caret to the beginning of the
previous writable icon in the window, the caret wraps around from last to
first and first to last as per arrow keys with KA.
IF KD is present in the icon's validation string, pressing any of
<Copy>,<Delete>,<Shift>+<Copy>,<Ctrl>+U,<Ctrl>+Copy will notify the
application with the appropriate key code as well as doing its defined
action as defined in the RISC OS 2.00 PRM.
IF KN is present in the icon's validation string, the application
will be notified about all key presses in the icon, even if they are handled
by the WIMP.
Options can be combined by including more than one option letter after the
K command (e.g. KAR will give the arrow and return functionality).
----------------------------------------------------------------------------------
From version 2.92 of th WIMP onwards, if the wimp can't find the sprite for
a non indirected sprite, or sprite+text icon, it will look the sprite in the
WIMP's sprite pool
after using a font for some time, if I unset Wimp$Font,
various things don't seem to work properly - eg. typing into a
writable icon leads to the caret disappearing?
not sure if this is repeatable, but it definitely happened.
thereafter the system is unreliable, and can often crash, saying
that the window with the caret cannot be found.
random background colour at times - sometimes white, green, black...
if an icon says 'don't fill background' you should use the
window background colour.
some menu entries just missing - white foreground colour?
'Illegal character in font string' sometimes - e.g. when opening
windows. Can vary for identical actions, so reading garbage values
somewhere.
(due to badly terminated strings)
In some text+sprite icons, the sprite is missing - blanking the
background on font_paint?
Perhaps related, *sometimes* on a text+sprite the text background
partially obscures the icon itself - most noticable on SCSIFiler icons,
but not always there.
default action button built using "R6 14" in validation string:
goes black when pressed, instead of orange.
Caret sometimes in the wrong position in writable icons, particularly
when they are initially created.
The l40 icon type does not work with this font.
Use of a scalable font as the system font
-----------------------------------------
[The facilities should be turned on and off on a per-task basis, based on
the Wimp version number quoted in Wimp_Initialise.] Wouldn't it look a bit
silly for some tasks to have system-text menus, and others not?
[Provide a global override that forces all tasks to do it, or forces no
tasks to do it.] The former should always be true; the latter would be an
option if the font you use is System.
[Provide a 'right align' character in text icons.] This is a better form
of text icon - one of the things to be addressed in Aquarius. (And how do
you measure the length such a string - does this require changes to the Font
Manager too?)
[Provide underline on/off control in icons.] Also part of a new text
icon, to be delivered by Aquarius.
[Provide separate control of the exact spacing between sprite and text.]
This is no new functionality: merely a question of changing the place the
job is done. It makes the lives of application writers slightly easier if
they can guarantee they will run under WIMP 3.2 only, but gives no new
facilities of any sort (the kind of feature called "sugar").
[Allow the app to get hold of the font handle of the wimp font.] How
about 'font_find_font ("<Wimp$Font>", ...)'?
[Add a 'shift' character to Homerton.Medium (and others) from
Symbol/Sydney.]
[Make the L40 icon type work as a writable field.] Again, facilities
like this should be available as a result of Aquarius work.
[Update the Task Manager, Palette Utility, ADFSFiler, SCSIFiler, NetFiler
and Filer to use scalable fonts.] If all WIMP-printed system font were to be
replaced by a scalable font, none of this would be needed.
[Bug fixes in DDV's code, including colour handling, L40 icons, caret
handling and automatic menu width calculation.] Fair enough, but wouldn't it
be faster to give them to DDV to do?
(Aside: I don't know what the brief of this work was, but it seems
to be that the best way to approach the problem would be to have the
WIMP produce text using <WIMP$Font> instead of system font, whereever
any text is supplied. The font would always be rendered at a size such
that the CharBBox of the font is 16×32 O S units. This would mean no
changes would be necessary to most applications, including all those
listed above. Right-justification in menus would be done by some
heuristic involving scanning for a regular expression that matches
all key names. What a shame that the regexp code in ROM isn't
callable.)
Other updates to improve graphic design
---------------------------------------
[Add facilities to allow the tiling of the background of a window with a
sprite.] This would be done by Aquarius.
[Provide a validation string facility in icons that specifies that the
background colour should be the same as the window background, using the
same tile, aligned to the same base.] This is form of transparency, which I
think will be treated by Aquarius too.
[Provide a new 3D startup screen, along the lines proposed by Chris
Murray's sketch.] This is not done by the WIMP, but by the Desktop module.
In any case, Service_DesktopWelcome (if claimed) will let any module
suppress it and replace it with something of its won devising.
[Change the visual feedback for action buttons and default action buttons
such that they sink down and to the right by one pixel.] At the moment,
there is no feedback of any sort here; it might be hard or easy to do this
in the WIMP. In any case, it would be of only limited usefulness, since the
way buttons should work in this paradigm is "down on click," "action on
RELEASE." To do this, we either have to change the icon button types used by
appications, or else provide a better way of doing this: in Aquarius, for
example.
[Radio icons where ADJUST can *not* lead to no buttons being selected.]
Sugar.
[Update drag-a-sprite.] As well as the WIMP, the font manager, a
selection of fonts, the task manager, the palette utility, ADFSFiler,
SCSIFiler, NetFiler and the filer? Okay, boss!
[Flashing caret.] This can be done already (though it would be nice if it
were done under interrupt ...).
[In a centred text icon, where the text is too wide for the icon, make
the text right-justified.] Sugar.
[A different crawling drag box.] Facilities to allow better application
control of the drag box belong in Aquarius: it should certainly be possible
to this there.
[A facility that allows the application to know whenever the value of a
writable icon changes.] Available already: set KN in the validation string.
[Add a slider/thermometer type icon.] Certainly a part of Aquarius.
[X in icon validation string.] Again, the sort of thing to be addressed
by Aquarius.
[Beep if a Wimp validation string prevents the typing of a key.]
Again, you can do this already by setting KN in the validation string.
[Investigate extracting all icon-rendering code from the Wimp into a
separate module.] An Aquarius sort of thing to do as well: I would hope that
all the facilities of WIMP icons would be available in the Aquarius toolkit.
That being the case, once we have Aquarius in wide use, the WIMP icon code
would no longer be in use, so could be taken out.
Updates to improve the handling of error messages
-------------------------------------------------
[Extra icons and buttons on Wimp_ReportError boxes.]
[Extra modes of behaviour for various classes of error.] The WIMP has
nothing to do with this, does it? Maybe we want a shared C library with a
trap handler that calls Wimp_ReportError with some of the new flags (if it
thinks the WIMP is running ...).
[Provide an escape route such that separate modules can provide handling
of specific error codes.] This sounds like a major system-wide change, on
the order of service calls (and I don't mean adding a new service call - I
mean like the whole service call mechanism).
[Provide a central facility that allows a single messages file to contain
messages for common errors.] This would be approached by Aquarius.
[Shift-control-ESCAPE should kill off the current task.] This can be done
at present using a small module.
[Go through the errors in the ROM (in hdr.newerrors), adding the above
classifications.]
Summary
-------
Changes that would come out of Aquarius anyway:
[Provide a 'right align' character in text icons.]
[Provide underline on/off control in icons.]
[Make the L40 icon type work as a writable field.]
[Add facilities to allow the tiling of the background of a window
with a sprite.]
[Change the visual feedback for action buttons and default action
buttons such that they sink down and to the right by one pixel.]
[Provide a validation string facility in icons that specifies that
the background colour should be the same as the window background,
using the same tile, aligned to the same base.]
[Add a slider/thermometer type icon.]
[A different crawling drag box.]
[X in icon validation string.]
[Provide a central facility that allows a single messages file to
contain messages for common errors.]
Changes to the WIMP:
[Bug fixes in DDV's code, including colour handling, L40 icons,
caret handling and automatic menu width calculation.]
[Extra icons and buttons on Wimp_ReportError boxes.]
Changes to other modules:
[Add a 'shift' character to Homerton.Medium (and others) from
Symbol/Sydney.]
[Update the Task Manager, Palette Utility, ADFSFiler, SCSIFiler,
NetFiler and Filer to use scalable fonts.]
[Update drag-a-sprite.]
[Flashing caret.]
[Extra modes of behaviour for various classes of error.]
[Shift-control-ESCAPE should kill off the current task.]
[Provide a new 3D startup screen, along the lines proposed by Chris
Murray's sketch.]
High-impact system-wide changes (which J R C considers impractical):
[Provide an escape route such that separate modules can provide
handling of specific error codes.]
[Go through the errors in the ROM (in hdr.newerrors), adding the
above classifications.]
Changes considered (by J R C) unnecessary or sugar:
[The facilities should be turned on and off on a per-task basis,
based on the Wimp version number quoted in Wimp_Initialise.]
[Provide a global override that forces all tasks to do it, or
forces no tasks to do it.]
[Provide separate control of the exact spacing between sprite and
text.]
[Allow the app to get hold of the font handle of the wimp font.]
[Radio icons where ADJUST can *not* lead to no buttons being
selected.]
[In a centred text icon, where the text is too wide for the icon,
make the text right-justified.]
[A facility that allows the application to know whenever the value
of a writable icon changes.]
[Beep if a Wimp validation string prevents the typing of a key.]
[Investigate extracting all icon-rendering code from the Wimp into
a separate module.]
Specification for a Proportional System Font under the Window Manager
=====================================================================
History
-------
0.01 WS 29-Oct-92 - started - just wimp font work provided.
0.02 WS 30-Oct-92 - feedback from JCoxhead, IJohnson, MChallis
0.03 WS 03-Nov-92 - more issues added.
0.04 WS 05-Nov-92 - review by WS,JC,DDV,IJ:
wimp font v system font terminology sorted out
('system font' still used to denote the built-in thing,
eg. on menu entries where there is a font choice)
control over aspect ratio added
various issues resolved
Wimp$SymbolFont added
auto-tabbing taken out
spec of distribution front end taken out
Issues
------
MChallis says, a long way from being a spec - very true! Long journey
starts with first step...
Baselines of font text may still be a problem?
WS will re-tweak the mode 12 font to have only one pixel of descender:
then review again.
WS 6th Nov - editing templates example - you have a label and a display
field lined up horizontally, but they are different vertical sizes. Their
baselines are lined up. Now change to the outline font and presto: their
baselines are no longer lined up! Aaagh! Or, they can be OK at lo res but
not at hi res! I think the baseline will have to stay PRECISELY where it was
for the wimp font, not at all nice.
Spec of call to Wimp_ReadSysInfo not precise.
In RO3 why did we do keyboard shortcuts capitalised when it isn't like that on
the keyboard? The current Style Guide mentions "Esc Print Insert Delete Copy Home
PageUp PageDown" (page 51-52) - presumably Tab Enter Return also allowed?
Surely a menu entry "Print Print" looks rather silly - if the shortcut is the
same as the menu entry proper, is it acceptable to omit the shortcut? Asking
Style Guide folks.
Ws and Ys for Welsh are in the range 80-8b, surely they should be taken from
the normal font rather than the symbol font? This is what I have assumed in
the text. Reviewers please confirm!
JC: The rule for menu shortcuts fails to internationalise: we believe that
German machines do not use ^, but rather an abbreviation, to mean 'control.'
It also fails to catch ^F1, shift-PRINT etc etc.
(WS): It does catch them! Don't understand.
Background
----------
This is a detailed specification for a package of changes current required
to the Window Manager, and some related modules, by the Libra project. Refer
to Libra market requirement, feasibility statement for further background.
Within the Victoria project I am trying (hard!) to move further towards
writing and reviewing specifications before they are implemented, to
specifications being more complete, and to sticking rigidly to those
specifications. This is a further experiment at achieving this, under
somewhat different project circumstances and for much smaller tasks. Refer
to Mike Challis' current document about what a functional specification
should contain.
All work should be done to full product quality. The enddate does not
correspond to a product release, but the result is likely to be integrated
into a product release in the future. Because of this it is vital that bugs
are not introduced in the course of this development work. Specifically it
is likely that we will release it informally to some high-end users and
developers during 1993, and that it will subsequently become part of the
Victoria RISC OS release.
Any changes to this document should be agreed in advance (extensions AND
restrictions). Jonathan Coxhead, Ian Johnson, David De Vorchik, William
Stoye are the 'review committee'.
Any updates to the SWI interface implied by these changes should be added
to this document and agreed before being implemented.
This specification is written in terms of differences from the Window
Manager in RISC OS 3.10. Use the RISC OS User Guide, the PRM, and the Window
Manager itself, as the specification for this. If these differ in some
relevant area then this document should make an explicit choice between
them.
These new modules will be cut in to the next product release of RISC OS,
probably as part of Victoria. However, they may well get circulated before
then, particularly to high-end users who want the result and are prepared to
pay the memory cost of soft-loading a Wimp. In such a case the necessary
files will be shipped as part of !3DIcons. The complete specification for
this can be found elsewhere.
Use of a scalable font as the system font
=========================================
The objective is to entirely replace the use of the system font with the
use of a proportional font within the desktop, in order to make the result
more visually appealing. This may lead to some incompatibilities with
existing applications, but this will be minimised wherever reasonably
possible.
We expect that this will be used most by high-end users, and by those who
possess high-resolution (square pixel) monitors (referred to as VGA
resolution from now on). However, we do not want to exclude those with low
(TV) resolution monitors, and wish to provide them with a reasonable path
forward.
The basic approach is that we will continue to have a single font which is
used for most purposes within the window system. (This contrasts with Windows,
for instance, where numerous different fonts are used for different purposes).
For the purposes of laying out dialogue boxes etc. applications developers
should assume that this font is Homerton.Medium at 12-point.
We expect VGA-resolution monitors to be used with the normal anti-aliased font
as rendered by the font manager. We expect TV-resolution monitors to be used
with a hand-tuned bitmap of this font at 12-point.
Specification
=============
The following changes are required to the Window Manager in RISC OS 3.10.
The following system variables are used:
wimp$font name of the font to use
wimp$fontsize heigth and width of the font, in 16ths of a point
wimp$fontwidth width of the font, if different from height, in 16ths
of a point
wimp$symbolfont name of the font for symbol characters
If the variable <wimp$font> exists then these indicate the font and size
which is used as 'the wimp font'. This font is used by the Window Manager to
plot icon, menu and window title text that has until now been plotted in the
system font. The existence and values of these variables is checked at
desktop startup, and at a mode change, and when the broadcast
Message_WimpFontChanged (&400XX) is sent by any application.
If painting generates an error for any reason, then do not report an error
but fall back to the system font. (This is particularly important when
painting the error box itself).
The font named in wimp$symbolfont is used, at the same specified point size,
for the rendition of character codes &80, &84, and &88 to &8B. This
mechanism is required because there are some symbols and characters in that
range which are known to be used, and which are not provided in standard
Acorn fonts.
An application can get hold of the wimp font handle or the wimp symbol font
handle using the following call:
SWI Wimp_ReadSysInfo
on entry:
r0 = XXX (read wimp font handle)
on exit:
r0 = 0 (and other registers undefined) if there is currently no wimp font handle
r0 = wimp font handle otherwise
r1 = wimp symbol font handle
When using the wimp font or the built-in system font, perform
auto-computation of menu width. Simply ignore the width that the application
provides in Wimp_OpenMenu. Menus should be just wide enough to contain the
title, and all of the entries, in the menu.
In menus keyboard shortcuts must be displayed right-aligned. These
are detected using the following rule:
If a non-writable menu entry contains at least one space, and the character
after the last space is one of the characters in a string found in the
Wimp's Messages file, then then right-align everything after the last space.
In the UK this string will consist of "^\x8b" (hex 8B is the shift key in
the symbol font).
If a non-writable menu entry contains at least one space, and the caracters
after the last space exactly match one of the words specified in a list in
the Wimp's Messages file, then right-align everything after the last space.
In the UK this list will consist of
"ESC PRINT INSERT DELETE COPY HOME PAGEUP PAGEDOWN TAB ENTER RETURN
Esc Print Insert Delete Copy Home PageUp PageDown Tab Enter Return
F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12".
A new font Wimp.Symbol should be created.
This only has only the following characters defined:
80 - a tick (take from Selwyn &33)
84 - a cross (take from Selwyn &63)
88 - a left arrow (take from Sydney &DC)
89 - a right arrow (take from Sydney &DE)
8a - a down arrow (take from Sydney &DF)
8b - an up arrow (take from Sydney &DD)
These should exist as outlines, and as a tuned bitmap suitable for 12 point
in mode 12.
A tuned bitmap _240x120 should be provided which makes Homerton.Medium 12
point on a TV-resolution display show using no anti-aliasing.
Changes are required to the Filer and to NetFiler to make them work with
scalable fonts. Specifically the small and full info display modes need
adjustment. No changes are required to any program interfaces, nor to the
behaviour of the Filer to the user.
Changes are required to the PRM to reflect these facilities, next time
the PRM is updated. Such changes will be limited to the Window Manager
chapter. Changes required are:
the section on system font handling
the description of icons under Wimp_CreateIcon
the description of menu width and keyboard shortcusts under Wimp_CreateMenu
the description of Message_WimpFontChanged under Wimp_SendMessage
the new call to Wimp_ReadSysInfo described
Any screenshot that shows a window will also have to be changed. This need
only occur next time the User Guide is updated for some other reason.
Changes are required to the User Guide, mainly in the screenshots but some
small descriptive changes may also be required. This need only occur next time
the User Guide is updated for some other reason.
The Wimp command window still uses the built-in system font.
Implementation notes
====================
The auto-calculation of menu width has to be fast - it is called
whenever a menu is opened or reopened.
It may be that the easiest way to right-align menu entries is to provide a
right-align control code in text icons. I cannot think of any other reason
for providing this. At the moment the we do not specify whether or not this
is the implementation mechanism.
Paint and Calc both make minor use of direct painting using the built-in
system font. Neither of these uses is important or noticable enough to need
fixing for release of this code.
Done
----
Wimp$Font, Wimp$FontSize, Wimp$FontWidth.
A new font, WIMPSymbol, has arrows (left, right, up, down) which may be
used in any icon (whether in the WIMP font or in a locally-defined scalable
font). It may also be used in documents in the same way as any other font.
It is loaded into ResourceFS along with the other ROM fonts.
Desktop font in L40-type icons. Text is filled and centred, both
horizontally and vertically.
New Filer Templates file gives left-justified file names in directory
displays. This is included in the new WIMP.
All known bugs fixed.
Dynamic computation of menu width.
Parse menu entries and right-justify shortcuts.
To do
-- --
Check the font variables on Message_WimpFontChanged and take appropriate
action.
Change the Filer such that the Full Info display uses icons for the
information, rather than system font text. (When this happens, the Filer
templates should probably be taken out of the WIMP.)
Fix the bugs reported by William:
Impression writing outside work area - never seen that before, happens
a lot. Somehow broken clipping there. Impression windows are
'unbounded' by the screen - could this be affecting it?
NetFiler crashes when Impression is loaded! Don't know why.
The baseline of icons in the wimp font should be precisely where it
was with the system font.
Sometimes you don't fill the background when painting an icon.
Example, in Edit's Find box: try to find a string 'xxx' which isn't in
the current file. The messages 'searching' and 'not found' are written
on top of each other, without clearing the bottom one.
Some menus which consist of a writable icon shrink considerably,
leaving an uncomfortably small area in which to write. Maybe the
quoted menu width should be taken as the minimum width? Not sure. I
realise this is a change to the spec. The 'new directory' entry in the
Filer is a good example. If people want to achieve this effect they
can always pad the title bar with spaces!
I think it would be better if the Filer templates were not included in
the Wimp - I can soft-load them separately. The WimpSymbol font, and
the Homerton.Medium tuned bitmap, should however be in the Wimp.
I suppose, for soft-loading on RISC OS 3.11, that the Sprites and
Tools resource files could in fact be found by peeking into the ROM.
This is naughty, but saves 44K of soft-loading space which is quite a
lot. Hum, this means that Wimp will not work with future OS releases -
but then, future OS releases will not need it (I assume!). So, overall
I think this is worth doing.
I think it's worth doing the updates to the Filer and NetFiler, when
the Wimp is believed complete. Steve Cormie has recently made a change
or two to the Filer to incorporate solid dragging I believe, I don't
know if he has checked these in so please make sure that he has.