Creating a docked window

Looking at the specification, it seems to me that behaviour previously handled as panes would be better thought of as child windows, which are windows in their own right, only nested within another (clue in the name! ;) ).

Indeed, the word “pane” only appears twice.

it seems to me that behaviour previously handled as panes would be better thought of as child windows

I share the same thoughts.

I did use Panes in the LaunchPad, but only as Furniture Window. For instance the top-pane is actually a child Window and that is because a Pane would cause troubles there with the get caret/lose caret events in the writeable icon.

Also, I always used the approach of creating first the main window/parent (so, never played with tricks of opening it after the nested windows, because that causes troubles with the nested windows).

There is another important detail that I am not sure if it has been discussed in this thread already:

The PROC/function that handles the OpenWindow event should always immediately check if the event is for:

• a move
  • Normally, if it’s a move, all is needed is to just OpenWindow the main window and then exit immediately, this reduces a lot the CPU load and works absolutely fine when using nested windows even on RISC OS 3.10 (as a matter of fact my LaunchPad works totally fine from RISC OS 3.10 + Nested WindowManager onwards). If nested correctly RISC OS should take care of closing everything with a CloseWindow event, Iconise everything by itself, and handling the go-to-background/go-to-foreground for every piece in the “window conglomerate” without the developer intervention, which is why Acorn said it was much easier.
• a resize or a first open
  • If it’s a resize or a first open event then the procedure should also OpenWindow the nested windows and resize them (if needed), eventually calling for a redraw if the resize also requires a re-arrangement of the window content.

What I usually do (well did in the past lol) is, if the redraw is complex and/or requires more than a certain amount of time then (in C it’s easier) I create a queue of “Background Iterative Partitioned Processes” that needs to be handled during Null Events. So, such work gets done in “partitions” during multiple null events. This allow the Desktop to stay responsive even during really complex operations, but indeed requires some skills at coding the iterative partitioned algorithms.

Please note: partitions are not threads. A partition should be seen as an “horizontal cut” of a procedure if we imagine a thread has a “vertical sub-process”. RISC OS multi-tasking code requires mastering partitioning due the lack of a preemptive scheduler which forces a developer to design algorithms to have full control over their execution in order to be able to return control to the Wimp and avoid to stale the entire desktop.

I remember that CoRoutines could also be helpful on this. Too bad BBC BASIC needed assembly to support CoRoutines efficiently (IIRC it worked fine only with RiscBASIC compiler, not so much with ABC, but I could remember wrong). However, it can be done in pure C or C mixed with Assembly (this works better with auxiliary stacks).

Background Iterative Partitioned Processes

PipeDream had this right from the start to avoid having to complete a potentially lengthy redraw (remember that 8MHz clock!) when it spotted that other events were pending, and could continue with the redraw under Null events if it hadn’t actually been perturbed by them.

If your toolbar covers part of the main window, you will have a lot of redraw occurring

I wonder if this was just a RISC OS 2 thing?

It turns out this is another thing answered by the Nested Wimp Functional Spec… Section 3.2.1:

“The way in which the Wimp calculates the invalid and block-copy rectangle lists is optimised over old Wimps, in order to increase the proportion of block-copy operations, which are usually much faster than redraws. This is done by compiling a list of changes between each call to Wimp_Poll, and only then calculating which rectangles are genuinely invalid, and which can be displayed using a quick block-copy operation. The block-copies themselves are re-ordered so that wherever possible, one copy does not invalidate screen area needed as source for another copy operation; in the rare cases where this is not possible, the least damaging alternative is chosen – that is, the one requiring the smallest invalid area to be redrawn.

“The upshot of this is that wherever touching or overlapping windows move together – external and internal panes, and of course, nested windows – the shuffling effect present in earlier Window Managers, where an area is alternately covered by the top window, and exposed and redrawn, is eliminated. There is also some speed gain from combining block-copy operations. In the unusual event that the window opening queue needs to be flushed before the Wimp_Poll, an extension to Wimp_OpenWindow is provided.”

So it’s a non-Nested Wimp thing, by the look of it.

If your toolbar covers part of the main window, you will have a lot of redraw occurring

Sorry, the post above mine mentioned “pane” so I was thinking of the toolbar in form of a pane window in non-nested Wimp mode.

Sorry, the post above mine mentioned “pane” so I was thinking of the toolbar in form of a pane window in non-nested Wimp mode.

Even this varies between Nested and Non-Nested Wimps, because (as I posted above) the Nested Wimp appears to have made some significant optimisations to the way that work areas are invalidated when windows move around – and this also affects “traditional” panes.

With the Nested Wimp, it doesn’t seem to matter too much what order the application moves and opens its panes, because the Wimp will wait until Wimp_Poll is called before working out what needs to be redrawn. Even the most idiotic algorithm doesn’t generate redraw events if there are no other windows nearby, because the Wimp optimises the unnecessary bits out.

Prior to the nested Wimp, however, you’re absolutely correct. In fact, on RO3.7 and Wimp 3.69 (which is as far back as I’ve gone so far), the approach that Steve D and I had gravitated towards (open the main window, then open the panes in order behind the same window that the main window was opened behind) results in really bad flicker as the pane and main window alternate around each other.

Trying my original idea (open the panes first, in descending order, then open the main window behind them) is better: there’s no visible flicker, but there are still a steady stream of alternating redraw events for the main window and toolbar, although I’ve not yet checked which bits of the work areas they’re for.

My gut feeling at present is that we need a mix of the two approaches: for the initial opening:

SYS "Wimp_OpenWindow",,main%
PROChandle_panes(main%)

so that we capture the window’s true position once opened, before setting up the pane(s), but then for redraw events

IF !b% = MainWindow% THEN PROChandle_panes(b%)
SYS "Wimp_OpenWindow",,b%

where PROChandle_panes() updates b%!28 on exit to be the handle of the bottom pane, so that we keep the stack order correct throughout.

More analysis is probably required, but I think the summary here is that the easy option is to limit yourself to the Nested Wimp (either with traditional panes, or parent/child windows) and don’t worry too much about how it works as the Wimp will fix it all up. However, if you want it to work on all versions of the wimp efficiently, then real care needs to be taken in the order that the windows are opened, as non-nested versions of the Wimp will redraw everything (with predictable results) if you give them half a chance…

I think the problem is that you need to open the main window first in order to find out how the Wimp is actually going to open it (position and size). Then the panes are opened, and finally the main window again behind the lowest pane.

I think the summary here is that the easy option is to limit yourself to the Nested Wimp …

It is probably the fact that I was testing out panes around the time the Nested Wimp was released that I never had any problems. I can see how there could be trouble with earlier vesions and that somewhere there was an ur-version of the code for handling panes that has persisted to this day, which does more than necessary for modern machines. ¹

¹ Anything this millenium. ;-)

the approach that Steve D and I had gravitated towards (open the main window, then open the panes in order behind the same window that the main window was opened behind) results in really bad flicker as the pane and main window alternate around each other.

That’s interesting, given the references to the Maestro code. I suspect that the current pane handling in Maestro is mine, rather than Acorn’s, as I changed quite a lot of the Wimp code when I started to work on it. Maestro’s main window doesn’t flicker on the system I normally use (RO5), so I assumed it was working fine, but I’ll have to try it out on a non-Nested Wimp to see if it’s flickering there (which I suppose it will do, given the current logic).

My gut feeling at present is that we need a mix of the two approaches: for the initial opening

That scheme looks sensible to me – if Maestro is flickering on pre-Nested Wimps, I’ll give it a try.