(below refers to macosx 10.5 and max 5.0.1 with all options of the Options menu enabled)
1. instantiate new jweb
2. connect readfile message
3. read a file from disk
4. open jweb inspector and enable scrollbars
5. scrollbars won't show until next launch of the patch
1. quit max
2. launch max
3. new patcher window
4. new object eg. notein (it's important not to click in empty space while creating objects, otherwise this trick won't work--instantiating should be done with ENTER)
5. new object eg. noteout
6. open inspector (cmd-i) on most recent created object (noteout)
7. if inspector opens on top of patcher window move it away
8. select other object (notein)
9. notice how inspector doesn't update
10. after having clicked somewhere else, selecting the objects will properly update the inspector's content.
minor inconsistencies or useful additions (I know demanding customers can really be annoying, but here I go):
The inspector window is designed to be continuously there (like the floating inspector of that other program, what was it called again) and while it can be empty when nothing is selected it cannot be opened without selecting an object.
Since the difference between a locked or unlocked patcher is visually speaking so tiny (the dots of the grid don't help too much, showing the grid a bit too much) maybe being able to change the color of the grid to a brighter one might be one (and yet another) option.
alt-clicking on a bogus object doesn't bring up bogus.help but instead max will try to find the help file of what the bogus contains (eg no help found for poobah). Also it appears that changing the default color for a bogus object doesn't have anymore effect, although it did have once, I think. Anyhow the background color for a single bogus object through it's inspector does not coincide with the created default for bogus, but with the default of a regular object. Changing that color doesn't update the object. (I'm so stuck now).
Initially I wasn't able to decide wether I wanted assistance because of the nervous flickering effect it has, but it is too useful to abandon it. A slight delay (option? help!) would overcome this, and the whole experience would be enhanced if the area which starts assistance (the size of the inlet or outlet itself) would upon starting grow one ore two pixels on either side so that the pointer doesn't have to be aimed at a relatively small area (crossing a relatively small area will start it, coming to a halt in a relatively bigger area will continue it). The same holds for having the messages and actions menu pop up.
With a maximized window the assistance of the toolbar options is offscreen.
In the scripting example of thispatcher, the scripted connection doesn't appear the first, but only the second time, after a disconnect.
The fact that autocompletion works only with adding characters and not with removing them can be tricky at times.
The ENTER key does instantiate objects but for messages or comments it's being interpreted as a new line a la RETURN. Extra click required (ok, shift+enter will also work).
Upon creating an object or a patch cord, it is selected (perfect) but cmd-clicking in empty space thereafter won't lock the patcher window but will deselect what was created. Only the second time will it lock (extra click required).
(Some of the things mentioned here are from the perspective of achieving the laziest as possible working method, in order to avoid physical damage, where every extra click or mouse movement is considered a useless effort. I normally work with a tablet (which isnt' too accurate, sometimes when clicking the pointer moves a pixel) and try to avoid bringing my writing hand to the keyboard a much as possible for reasons of speed.)
Here I'll stop, before I overdo it.