diff --git a/Chapters/ch09-an-embedded-toolbox.xml b/Chapters/ch09-an-embedded-toolbox.xml index 1afc9c8..2c38977 100644 --- a/Chapters/ch09-an-embedded-toolbox.xml +++ b/Chapters/ch09-an-embedded-toolbox.xml @@ -46,7 +46,7 @@

Back in the late 1980s, when RISC OS was a new system, space on the screens of the day was limited and there was a trend for using minimalist toolboxes embedded into the space used by the scrollbars of a window. Of the numerous applications which used the technique, the original Ovation is still well-known – its take on the idea can be seen in .

- +

At the time, Ovation’s author created this effect using three windows, which are all interleaved carefully. These days, the effect can be achieved more easily using the Nested Wimp, and in previous chapters we have already seen examples from Paint () and NetSurf () in passing.

@@ -102,7 +102,7 @@ SYS "Wimp_GetWindowInfo",,toolbox% OR %1

Working out the horizontal position of the new toolbox should be a familiar process. We will be anchoring it to the left hand side of the main window’s work area, as shown in .

- +

As we currently have nothing to go into the toolbox, the width is largely immaterial and so for now we will set it to 200 OS Units.

@@ -113,9 +113,9 @@ SYS "Wimp_GetWindowInfo",,toolbox% OR %1 toolbox%!4 = main%!4 : REM Visible Area X0 toolbox%!12 = main%!4 + box_width% : REM Visible Area X1 -

Positioning the toolbar in the vertical dimension, however, is more tricky than anything which we have encountered up to now. As can be seen in , we need to ensure that the top and bottom outlines of the toolbox line up with the top and bottom outlines of the main window’s horizontal scroll bar.

+

Positioning the toolbox in the vertical dimension, however, is more tricky than anything which we have encountered up to now. As can be seen in , we need to ensure that the top and bottom outlines of the toolbox line up with the top and bottom outlines of the main window’s horizontal scroll bar.

- +

The Y0 coordinate for the toolbox visible area must line up with the Y0 coordinate of the main window’s outline. As we saw in the previous chapter, the outline includes the window border, and so its X0 is one pixel further down the screen than the X0 of the visible area will be.

@@ -130,13 +130,13 @@ toolbox%!12 = main%!4 + box_width% : REM Visible Area X1 SYS "OS_ReadModeVariable", -1, 5 TO ,,eigenfactor% pixel_height% = 2 ^ eigenfactor% -

With the toolbar positioned, the final thing to do before opening it as a child window is to use Wimp_SetExtent to ensure that the extent is sufficient to cover the whole visible area.

+

With the toolbox positioned, the final thing to do before opening it as a child window is to use Wimp_SetExtent to ensure that the extent is sufficient to cover the whole visible area.

toolbox%!52 = toolbox%!44 + box_width% toolbox%!48 = toolbox%!56 - box_height% SYS "Wimp_SetExtent", ToolBoxWindow%, toolbox% + 44 -

The toolbar is anchored a little differently to what we have seen before, as it is connected to the left and bottom of the main window’s work area. This results in us using flags of &05550000.

+

The toolbox is anchored a little differently to what we have seen before, as it is connected to the left and bottom of the main window’s work area. This results in us using flags of &05550000.

toolbox%!28 = -1 @@ -144,7 +144,7 @@ SYS "Wimp_OpenWindow",,toolbox%, &4B534154, !main%, &05550000<

Bringing all of these changes together results in PROCopen_main_window looking as shown in .

-DEF PROCopen_main_window +DEF PROCopen_main_window LOCAL screen_width%, screen_height%, window_width%, window_height%, main%, main_outline% LOCAL toolbox%, box_width%, box_height%, eigenfactor%, pixel_height% @@ -234,22 +234,22 @@ toolbox%!28 = -1 SYS "Wimp_OpenWindow",,toolbox%, &4B534154, !main%, &05550000 ENDPROC -

Running the application will produce a window with a toolbar embedded into the horizontal scroll bar, as seen in .

+

Running the application will produce a window with a toolbox embedded into the horizontal scroll bar, as seen in .

- +

The application as it stands so far can be found in .

- +
Adding some icons -

A toolbox isn’t much use without some icons in it, so the next thing that we will need to do is add some. Unlike all of our previous panes, however, the critical dimension – the height of the toolbar window, which will determine the size of the icons within it – is dependent on a factor outside of our control. It is defined by the height of the horizontal scroll bar, which in turn will depend on the desktop theme and mode that user has selected.

+

A toolbox isn’t much use without some icons in it, so the next thing that we will need to do is add some. Unlike all of our previous panes, however, the critical dimension – the height of the toolbox window, which will determine the size of the icons within it – is dependent on a factor outside of our control. It is defined by the height of the horizontal scroll bar, which in turn will depend on the desktop theme and mode that user has selected.

-

As a result, we will need to arrange the icons in the toolbar as we align it to the main window. This isn’t a problem: we’ve already seen how to move icons around using Wimp_ResizeIcon in several of the previous examples – it just adds another step to the process of opening the window.

+

As a result, we will need to arrange the icons in the toolbox as we align it to the main window. This isn’t a problem: we’ve already seen how to move icons around using Wimp_ResizeIcon in several of the previous examples – it just adds another step to the process of opening the window.

The first thing that we will do is to add four icons to the “Embedded” window template. Since we will be adjusting their size and position when the window is opened, it doesn’t matter where they go in the template: for ease of editing, we’ve done it as seen in . Keeping them in numerical order by their handles, from 0 on the left to 3 on the right, will make working on the design a lot easier!

@@ -257,7 +257,7 @@ ENDPROC

Given that space is limited, we will lay the toolbox out with the minimum of wasted real estate as shown in : a border of one pixel around the outside of the icons, and one pixel between each icon. Usually icons are placed on a 4 by 4 OS Unit grid to ensure that designs will work in all modes including the old rectangular pixel ones found on early systems (see the Style Guide for details), but we’re reading the mode details when we arrange the toolbox and so only need to match the capability of the current screen mode.

- +

As before, we start by reading the vertical size of a pixel in OS Units, and use that to calculate the height of both the visible area and work area of the toolbox – the value, also in OS Units, is stored in the box_height% variable. Once we have this, we can use it to calculate the height of an icon: the height of the toolbox, less a pixel above and a pixel below. The value is stored in the icon_height% variable.

@@ -282,7 +282,7 @@ icon_width% = (icon_height% + (pixel_width% - 1)) AND (NOT pixel_width%) box_width% = toolbox%!88 * (icon_width% + pixel_width%) + pixel_width% -

Armed with all of these dimensions, we can lay the toolbar’s visble area out as before. Once that is done, we must step through each icon in turn and update its pisition using Wimp_ResizeIcon.

+

Armed with all of these dimensions, we can lay the visble area of the toolbox out as before. Once that is done, we must step through each icon in turn and update its pisition using Wimp_ResizeIcon.

FOR icon% = 0 TO toolbox%!88 - 1 xpos% = toolbox%!44 + icon% * (icon_width% + pixel_width%) + pixel_width% @@ -297,11 +297,18 @@ NEXT icon% -

One of the things that is worth noting here is the very limited – not to mention variable – space available for the icons in the toolbar. Care needs to be taken when designing the contents, to ensure that it can handle different screen modes and sizes of scroll bar whilst remaining clear and intuitive to the user. This is a problem that is getting worse as screen sizes reduce, and it may be that in a modern application, such toolbars are best limited to the kinds of uses seen in Paint () and NetSurf ().

+

One of the things that is worth noting here is the very limited – not to mention variable – space available for the icons in the toolbox. Care needs to be taken when designing the contents, to ensure that it can handle different screen modes and sizes of scroll bar whilst remaining clear and intuitive to the user. This is a problem that is getting worse as screen sizes reduce, and it may be that in a modern application, embedded toolboxes are best limited to the kinds of uses seen in Paint () and NetSurf ().

The full application with the code to position the icons can be found in .

- + +
+ +
+Changes of mode + +

Although our new toolbox +