Unfluffing the Dictionary

[tperry2x]

The more and more you read of the dictionary, the more this applies:

[richmond62]

mobileCreateLocalNotification command.txt

the number of seconds since the UNIX Epoch

I am NOT going to change that.

[richmond62]

The problem is that the Dictionary rabbit hole is not a literary rabbit hole like Lewis Carroll's one in "Alice in Wonderland" (i.e. linear and going straight down).

It is far, far more like a real Warren where the conies have burrowed off in all directions and set up several entrances.
-

Bunnies.jpg (71 KiB) Viewed 1481 times

-
ANYWAY . . .

I will TRY to sort out the UNIX refs, and then the mixed-Mac refs to the extent that I can: and, after all, if the Dictionary ends up 50% better owing to my efforts that beats a whack in the face with a sharp stick.

[richmond62]

And, before the Rabbit-Protection Conservationists raise their ugly placards: I AM risking offending a few purists:
-

Screenshot 2024-12-03 at 12.11.15.png (41.41 KiB) Viewed 1480 times

[richmond62]

mouse button glossary.txt

"Usually, the mouse on a Mac OS or OS X|OS X system has one button, the mouse on a Windows|Windows system has two, and the mouse on a Linux|Linux system has three."

Emphasis is mine.

The last time I saw a single button mouse attached to a Mac was in 1999.
-

Screenshot 2024-12-03 at 12.17.06.png (79.38 KiB) Viewed 1479 times

-
Yes: I have one of those, and, occasionally, I attach it to a computer just to wind some teenager up.

I have inserted this:

"This is almost entirely redundant as most computers have 3 button mice regardless of which operating system they are running."

Both my work Macs have this type of mouse connected (with 5 buttons):
-

Vertical.jpg (18.91 KiB) Viewed 1478 times

-
I cannot recommend them enough: NO wrist pain.

[richmond62]

Wow! I have to keep my wits about me:

"Because OS X is based on Unix"

Had I changed that to

"Because OS X is based on Linux"

I would have looked a right prawn.

Anyone who mentions a "simple search and replace" to me again is likely to get a fairly rough reception.

[richmond62]

Well, well, that's another 34 "gone through", so off for lunch.

The attached ZIP file ONLY contains the 34 documents I have just processed.

[richmond62]

pageCount property.txt

Description:
Use the pageCount property to find out how many pages are in an EPS|EPS object.

This property is supported only on Unix systems with Display PostScript installed.

This term is probably redundant as OpenXTalk does not currently run on Unix systems.

Values:
The pageCount of an EPS|EPS object is a positive integer. This property is read-only and cannot be set.

My addition highlighted in orange.

[richmond62]

paintCompression property.txt

-

Screenshot 2024-12-03 at 15.01.14.png (79.9 KiB) Viewed 1465 times

-
Hmm?

PICT

https://filesamples.com/formats/pict

On Mac OS and OS X|OS X systems, PICT files can be import|imported

NOT into OXT Lite 1.09 on MacOS 12.7

I have NOT corrected this BUT it would be interesting to know at what stage Apple abandoned the PICT format.

This is NOT helpful:

https://en.wikipedia.org/wiki/PICT

[richmond62]

play command.txt

In the light of recent work this maybe redundant, or wrong:

On Linux systems, the "xanim" program must be located in a directory in the PATH environment variable.

Please can someone check this and, if necessary, sort it out.

[richmond62]

print command.txt

On Unix|Unix systems, the print command creates a PostScript|PostScript file and runs the program specified in the printCommand property, with the file as input.

This information is probably redundant as OpenXTalk does not currently run on Unix systems.

AND, I would suppose that this makes no sense in terms of Linux.
-

quotes-hitchhikers-guide-galaxy-10.jpg (150.03 KiB) Viewed 1454 times

[richmond62]

printerOutput property.txt

Values:
The printerOutput can be one of the following values. The default value depends on the printer driver

- Windows Vista uses XPS format.

This is probably redundant information as OpenXTalk does not deploy on Windows Vista.

- UNIX uses PostScript format.

This is probably redundant information as OpenXTalk does not deploy on UNIX

- Mac OS X uses PDF format.

Why the 'Fudge' Any of this has to be mentioned at all I just not sure.
-

7qgmtsa0qj831.png (45.11 KiB) Viewed 1452 times

[richmond62]

So, there's another 31 documents "under my belt", and that, "my darlings" is all you're going to get today.

Attaching 'the story so far'.

HOWEVER, even if only to protect myself: what with Windows Vista, Windows XP, UNIX, EPS, PostScript and some other distinctly outmoded stuff popping up

(feels a bit like when I went to Lentran to pick raspberries in 1980 with a map of Inverness-shire of my father's from 1952, and walking into the railway station at Inverness to ask for a ticket to Lentran was informed that Dr Beeching had closed Lentran station in 1964.)

I do feel that MOST of the files I have edited need further examination, even to the extent of testing whether OXT can do all the things on CURRENT Windows and Linux they state it can.

[richmond62]

I seem ONLY to have 61 documents left in my "contains UNIX" directory.

I am not sure whether I should feel good about that or not.

[richmond62]

revMacFromUnixPath function.txt

I really don't want to change any UNIX references in here:

"revMacFromUnixPath
(function)
Converts a Unix-style file path|pathname to a Mac OS-style file path|pathname.

Syntax:
revMacFromUnixPath({unixPathname} [, {convertOSX}])
----

Synonyms:

Params:
unixPathname ( ): A file or folder pathname in the standard format used by OpenXTalk for file paths.
convertOSX (bool ): If you don't specify the , if OS X is running, OpenXTalk assumes you want to convert an OS X-style path to a Mac OS-style path; otherwise, it assumes you don't want to convert between the OS X style and Mac OS style.

Examples:
revMacFromUnixPath("/usr/bin/stuff")
----
revMacFromUnixPath(it)
----

Description:
Use the revMacFromUnixPath function to convert a OpenXTalk-style file path to the Mac OS file path format (for example, if you need to pass a file path|pathname to an external).

The revMacFromUnixPath function converts slashes (/) to colons (:), the folder-level delimiter for Mac OS file path|pathnames. It also deletes leading slashes, so that file path|pathnames are rooted in the volume name (the standard for Mac OS file path|pathnames). It also adjusts relative pathnames.

On Mac OS systems, absolute paths always begin with the name of the disk that the file or folder is on. On OS X systems, the startup disk's name does not appear in absolute file paths. Instead, if a file or folder is on the startup disk, the first part of the file path is the top-level folder that the file is in. If a file or folder is on a disk other than the startup disk, its absolute path starts with "Volumes", followed by the disk name.

The OS X path convention is used by OpenXTalk, but the old Mac OS-style path convention is required by certain applications (such as AppleScript), even on OS X systems. If the convertOSX is true (or if you don't specify the convertOSX and the application is running under OS X), the revMacFromUnixPath function automatically converts absolute file path|absolute paths from the OS X standard to the Mac OS standard, adding the startup disk's name to paths that are on the startup disk, and stripping the "Volumes" element from paths that are not on the startup disk. If the convertOSX is false, the revMacFromUnixPath function does not make these changes to absolute file path|absolute paths.

OpenXTalk always uses the Unix pathname standard for cross-platform compatibility, and automatically converts pathnames to the correct standard for the current platform when executing commands. You need to convert the pathname only if you are passing it to another program or external. If you are using only OpenXTalk commands and functions, you do not need to convert the pathname, since OpenXTalk does it for you.

*Note:* When included in a standalone application, the Common library is implemented as a hidden group and made available when the group receives its first openBackground message. During the first part of the application|application's startup process, before this message is sent, the revMacFromUnixPath function is not yet available. This may affect attempts to use this function in startup, preOpenStack, openStack, or preOpenCard handler|handlers in the main stack. Once the application has finished starting up, the library is available and the revMacFromUnixPath function can be used in any handler.

Values:
The revMacFromUnixPath function returns a string with the file path in the format expected by the Mac OS.

OS:
mac,windows,linux"

My emphasis.

Neither with this one:

revUnixFromMacPath function.txt

[richmond62]

Coming across all that redundant stuff re EPS images and PostScript I stared wondering about Documentation and SVG image
handling.

I came across:

drawingSvgCompile and

drawingSvgCompileFile

which is insufficient, and someone needs to type up several files about SVG import

(It would seem that NOTHING has been added to the Dictionary re SVG images since the ability to import them was introduced).

The ability to import SVG images was introduced with LC 9.0.0 as far as I recall (2017).

[richmond62]

34 out of 61 documents "done".

A leg stretch and a cup of coffee are called for.

[richmond62]

AND!

"Macintosh schizophrenia".

Mac OS, OS X, Macintosh, and even Mac OS X

As Pre "X" is ancient, and OXT certainly does NOT deploy on, say, MacOS 9, and as Apple have also had some "mental problems"
re naming their operating system . . .

. . . even to the extent that it seems now to have reverted to MacOS (err; or macOS) after some 24 years . . .

I intend to replace ALL these confusing terms with MacOS.

Objections?

Please shout now, before I get started.

[richmond62]

OK: that's the 'UNIX' files "gone through" . . .

Of course a lot of them will go "back into the mix" for Macintosh schizophrenia.

I should think about 20% of those files contain outdated or redundant information referring only to UNIX . . .

I have NOT removed them; simply annotated them to that effect.

The attached ZIP file contains ALL the 'UNIX' files post-editing for UNIX.

I will roll them back into my personal copy of the 'resaved' folder and then filter that for Macintosh refs.

HOWEVER: my honest impression is that the inherited Dictionary is about 50% utter crap as it quite obviously lags behind LC 963 by a good 5-10 years.

Not only does it need editing: there also needs to be considerably number of additions.

[tperry2x]

I intend to replace ALL these confusing terms with MacOS.
Objections?
Please shout now, before I get started.

I have no objections. I'm certainly not planning on an OXT release for MacOS 9 any time soon.