PipeDream is an old, established program. Trouble is, it's too versatile and does too much, so although it is used (and loved) by lots, there's little call to improve it. However, it has survived with relatively little change since the early days and the rate of change nowadays is close to the imperceptible! There is little evidence that this state can be altered, and the reasons for this reluctance have not been divulged so I am left guessing.
I do still however have a vision for PipeDream. It was so in advance of its time that most of its concepts are as valid today as they ever were - in fact maybe it is only now about to come of age? However - RISC OS has moved on, so Pipedream, which uses early OS interactions is seen by many as being 'quirky'. PipeDream really pre-dated even RISC OS and RISC OS key conventions have not settled around PipeDream but have moved on somewhat. This really need not be: with some careful though and re-design PipeDream can be given a face lift and a shining new coat of paint which should bring it bang up-to date, once again a leading RISC OS program.
This then is a list of additions I would like to see. It is (hopefully) not simply a list of the additions I personally need - to be frank, I would not personally use many of these suggestions. More it is a list of how I see PipeDream being improved to make it much more modern and much easier for new users to get into. If you have other suggestions, or wish to vote for these improvements, please contact me.
I have divided this list into two parts: those which I believe should be reasonably possible to implement, given what I know of PipeDream's program, and those which are of unknown difficulty of implementation.
The timing of autosaves should be globally selectable, and there should be a global off switch.
But zero is a number and a blank is the absence of any entry so this evaluation is mathematically incorrect.
Save choices saves the current document's format as a default template for future use. However the new template is only used on the next session - the current default template remains in place until PipeDream is quit and re-loaded.
In the Choices sub menu, the 'Save Choices' entry should open another sub-menu which is the save box proper, and this should contain the full path and leaf name to which Choices will be saved. This is needed because Choices is saved to the first entry in the Makro PipeDream$Path - which is set by several system variables, so may not be immediately obvious.
This should be changed: 'Save choices' should have an immediate effect without quitting and reloading PipeDream.
If a PipeDream$UserPath has been set up, the position of this file defaults to being placed in the first directory in that path. However, the choices file contains lots of parameters and not all of these are used by PipeDream when it creates a new file. For instance, the Choices file contains Window Position. This is ignored.
All Choices in the Choices file should be obeyed when opening a new file. However - this probably implies that some choices should have a method of not being saved into the choices file. In the case of the Window position, this could be accomplished very easily by simply deleting the appropriate line from the saved file.
The new command (presumably \Fqz|m) should close the window without saving.
To explain this idea, PipeDream's screen is analogous to a series of transparent sheets overlayed, with each overlayed sheet being opaque only where the slot is not empty. This suggestion would effectively shade the 'opaque' bits.
A corollary of this is that 'select' should cause the caret to land up in the correct place, in the cell of the colour clicked on. This will probably happen anyway for the most part but needs to be considered.
Since this is the exact coloration behaviour already given by a 'protected slot' PipeDream already contains all the mechanisms for doing this, so the change should not be huge and would dramatically simplify the user interface.
Whilst we're thinking of colours, cells with formulae in should show up in a different colour from text cells.
So the proposal is for a new command to be added to the Layout menu, similar to the \Lfr command (Layout Fix Rows) which which would be \Lch (Layout Column Header). All the column data in that row would be printed as column headers in any printout. Screen display is not so necessary.
This could be partially accomplished via the proposed OSCLI command, see below.
Full implementation of conditional file loading would require a different sort of call to such external files. At present any external file is named in square brackets with a slot reference, e.g. [external]A1. I suppose a new file reference could be, for instance: {external}A1. PipeDream would then not pre-load any such named file when it found a reference to it.
However, the most likely use for conditionally loaded files would probably be as a method of inputting data to the main sheet. This could easily de done by the CLF using set_value(slotref,value) to write so the full implementation would probably be of less use - in which case the proposed OSCLI command would suffice.
However what you CANNOT do is, for instance, pass the leafname to a custom function and use that in the function to write back to the file calling the function. The example file leaf name illustrates this. It should write back 'fred' to slot B1. Instead it returns an error.
It would be far better if the 'Propagated' error actually said 'Error [filename]slot' so one could go directly back to the cause of the original error.
Unfortunately, the error box does not name the value which is not defined, nor does it name the file where it the value should be defined. Id does not even mention the name or cell of the calling slot which tried to read the undefined value! Since PipeDream must know all of these, it should not be a major task to make it divulge them to the user, resulting in a much more helpful error message. PipeDream's present behaviour is highly secretive!
This would be very useful in conjunction with Command files. Currently you can easily go to the start of the file, or to the end of the file and these two 'markers' are of course independent if the length of the file. But if the file is of a standard format, but of variable length, it is currently impossible to go to a place in the centre, as you do not know its cell number or how far it is from top or bottom of the file.
This suggestion arises because we use PipeDream for raising orders. These are of standard format, header and footer are always laid out the same, but the number of lines in the centre vary.
I'm sure the feature would have many uses once introduced and should not be at all difficult from the programming point of view.
This should be changed so that the path and leaf name is a writable icon in which the current pathname is shown. If you wish to alter the name, you can re-write here. The two click boxes should then be 'Discard' and 'Save'. There should also be a file icon to do a drag and drop save.
This is more intuitive and more in line with most modern applications - as well as saving a lot of clicks when quitting with multiple files loaded.
Also, the 'save' windows should not move between mouse clicks as at present!
Having a File Status option, attached to every file and saved with that file, would overcome this.
Possible statuses are
When a file is closed either by a command \Fc|m or by clicking on its close window, it should close according to its pre-defined status. The default status would of course be 'Ask'.
This is the action of Edit, StrongEd and Zap. But I would propose two 'hotkeys'. One will insert the full pathname, the other just the leafname.
This new feature would, I am sure, have many uses but one that I can see is for instance, to insert the name of an ArcFax file containing an order in a slot against the order details so the customer's original order could always be located - without having to pin a printout to the paperwork!
Such pathnames would simply be displayed as text the full path name, or the leafname only (with a different hot key). Pipedream would make no effort to display these.
It has struck me that PipeDream's own internal structure is in many respects similar to HTML. For instance its cell references are similar to HTML anchors. It can have names cells which has an HTML parallel and it references external files (e.g. Drawfiles) in a way very similar to HTML. Some consideration of these similarities could be useful and may extend PipeDream's interest by giving it a limited facility to export html.
Clearly HTML compatibility is a big ball-park and full compatibility would be a huge undertaking. But PD4 already includes mechanisms for cell referencing, and this mechanism could presumably be expanded to include a 'jump to cell' command, which would effectively be a hypertext link. This feature would greatly help in tracing program flow through custom functions!
Currently when one PipeDream window is closed, the input focus is transferred to the next window. PipeDream (pre-dating Iconising of windows) pays no heed to the Iconised state on the window, so Iconised windows tend to spring open when other windows are closed.
The problem with using this to implment contional file loading is that the usefulnessof the conditionally loaded file would be one way: the CLF could write to any existing file, but could not be called from a loaded file, or it would have already been loaded!
However - PipeDream has problems with embedded drawfiles. The RISC-OS system is that printing these is passed to an OS module (Drawfile) which does all the rendering. This module did not exist when PipeDream was designed, so PipeDream has its own draw file printing routines. These do not work properly with modern printers. In particular, PipeDream does not properly print fonts in draw files with any PostScript printing system.
A third, optional, argument would be useful. If present the this argument would tell the function what contents to set the slot to. For instance Set_type(A1,number,1) or Set_type(A1,text,1). The argument could, of course, be calculated.
It should be possible to write pure text into a slot! This requirement is probably interactive with the proposed set_type(slot,type) function, which may well accomplish this.
However, this function does not differentiate between number and formula. It should. Thus the function returns:
| Slot contents | Type |
|---|---|
| 4 | Number |
| 4+2 | Number |
This is also bound up with the 'Deref' function. But there appear to be no way to determine that the contemts of a slot contains a formula and so cannot be overwritten. This can be neccessary in, for instance, a custom function which is updating many slots. There should be a way of checking the slot for writability without writting to it and geting an error!
In the 'Save' window (or may be in a separate 'Window Position' box) you would have two sets of window numbers, 'Current' and 'Default'. There would be Icons
The behaviour of Iconised Pipedream windows currently is not good: see Iconised Windows.
| 2.00 | Widgits | 1.50 | 3.00 |
If empty cells retained a format, this would be written correctly as
| 2 | Widgits | £1.50 | £3.00 |
This page's URL: http://www.4qd.co.uk/ro/pd4/wish.html