Compo/PCA Applets manual

Excellent work on the draft.

Could the page alignment be shifted from the print centric left page right page setup to a straight aligned PDF centric model?
I suspect it may only rarely ever appear in dead tree format.

The effect is particularly noticeable at points like the page 19/20 rollover where indented sub-headlines have been used.

Minor items:
Section 2 “Tutorials” sections 9, 10 have multiple paragraphs and visually the two seem to run together – maybe a little more line space after the last para in each numbered item?

This para spacing may be a carry over from the visual presentation of the original, where perhaps they were cramming in content on a minimised number of pages.

Thanks. You’re right that I have tried to keep to the layout and pagination of the original despite its rather tight, not to say mean, use of space.

The left/right page layout again follows the original paper version which, as you say, might not be best for screen use. I will reconsider options.

I am now away for a couple of weeks, and will resume work and correspondence on my return.

@Bernard, thank you for this work and this new thread for !Compo
In this new thread the download link is missing.
Thanks.

After some travel and other distractions, I have found much to correct or query in the reworked manual. Its current draft is (as before) downloadable from here. On screen, it’s best read in a two-up display such as Foxit PDF Reader can do. (It’s a pity that !PDF doesn’t offer a two-up side-by-side display). The bookmarks help navigation: I cannot put hot links into the Contents.

I have several versions of Compo which don’t all adhere to the manual in every detail, and which also crash in various ways in diferent OS environments, so it’s probably impossible to make the manual definitive. I am writing up my queries and comments in a separate list which will appear alongside the draft manual shortly; others may be able to help answer some of them.

As always, I’d be pleased to hear from anyone using the apps.

The ‘different versions crashes’ behaviour may be due to factors like setting the values it assumes at bootup. Might be useful if we could assemble a public ‘table’ of what versions work or not on which OS versions/hardware etc. Also may be due to ‘helpers’ in the fleet of applets, etc, which the main prog cals to do various tasks for it. Again, pooling details may aid identifying the causes and fixes.

FWIW I was trawling though my files for the 2004-ish period to collect info as the basis of adding more to my ‘history’ pages and rediscovered the old email lists we ran for Compo and TechWriter. Maybe we should have a new Compo email list for users to share problems and fixes, and how-tos? That would make things like sharing test code, etc, easier as well.

Quite so. The !Run file contains this:

| Composition memory management
| Options are: "Auto" (this is the default)
|              "Wimpslot" (always use wimpslot - not recommended for RO 3&4)
|              "Dynamic" (always use dynamic areas - not a good idea on RO 5)
  
Set Compo$MemoryManager Dynamic

| Following is used for Dynamic areas only
| Being the address space of:
| "small workspaces" "large workspaces" and "canvas" respectively, in MB

Set Compo$AddressSpaces 8 32 128

Choosing ‘Dynamic’ seems to be required despite saying ‘not a good idea on RO 5’.
With large sprites, it may be necessary to increase the values of ‘Compo$AddressSpaces’.

A document on what works and what doesn’t and that includes questions to be resolved would be helpful. I was planning such a thing to go alongside the latest draft of the manual, which is on pCloud. To be shared for update it might be better to use Google Docs. What do people think?

There are probably better methods nowadays than an email list: suggestions welcome.

I’m a bit late in responding, but my preference is to like an email list. Given !Pluto, they are easy to search though to find info that isn’t ‘new’, and to raise questions other users may be able to help with.

However complete ‘new version’ documents are best as some sort of file(s). PDF is the obvious. But a set of interlinked HTML pages is an alternative as it is easy to add to without having to change to everyone getting and complete ‘new version’ when just one significant think has been added/changed. (Also mean some demos could be included that avoid recreation by the reader.)