Align, Bkgnd, Font, Frame, Spell

Extrapolating Redwood City. Extrapolating into the future.

Get It Try It

The work of NeXT was never completed. They'd put themselves years ahead of the industry, but there was still a lot to do when Apple punted $429 million for them in 1996.

But they must have had something. They'd only lost money, all those years. Things were looking a bit brighter by 1996, when they could finally project a profit on the coming year of about $300 million - still short of the buyout by $129 million.

NeXT had an object-oriented underbody and an object-oriented interface. By 1996 the world was going gangbusters with object orientation, but nobody was doing it right. In Palo Alto, LRG lead Alan Kay was shaking his head.

'I invented the term object orientation, and that's not what I had in mind', said Kay of one of the OO languages that popped up. One feels his pain. But what Brad Cox did with Kay's Smalltalk changed the world. For the better. Steve Jobs contracted for use of Cox' patented language, and NeXT got started, the results of which are seen today in iPhone, iPad, and the Apple watches.

Spatiality. A very abused term. First used widely when objecting to Apple's pretender file manager. You can't really have spatiality when you have a file system with tens of thousands of directories, a far cry from old Macintosh systems which mostly had 'one program and one folder to put it in'.

But when it comes to ordinary applications, the rules gladly revert.

Applications preferences files, thanks to the document controller, often contain references to the frame of the last opened document window. These frame coordinates are often given with both starting x/y coordinates and height and width for both the 'normal' frame and for the 'zoomed' one.

Which is all fine and good if that's what you want. But it's not object-oriented in the sense of being 'document-centric'. The document controller's job is to see that windows cascade, so that preferences file settings can be used to make sure the next window is the right amount further to the right and down.

Unless, of course, that's not what you want.

Here we have a classic community where spatiality in file management windows is something obsessive yet impossible, yet the idea that important document windows should do the same isn't even thought of. And while it's beyond ridiculous to think about getting 'spatial' with hundreds, thousands, tens of thousands of folder documents, it's conspicuously feasible with a half dozen or so ordinary application documents.

And thereby you approach what likely is the original vision of NeXT.

Rixstep already achieve this 'spatiality' in a number of ACP applications. Xbase is one. Xshelf is another. But, in both instances, the documents themselves are not otherwise going to contain plain and pure text.

(Both applications - all ACP applications, for that matter - are further helped by the ACP framework which can be enlisted to help clients on exit and cleanup, so no unnecessary flotsam and jetsam remains.)

But pure text files? How do you go about that? Especially when you - by definition - don't want to use extended attributes, seeing as extended attributes are not universally transportable?

Because they're not. Many FTP clients don't even recognise them. Other filesystems don't recognise them either.

But all filesystems recognise file extensions. Especially Unix systems, where a file extension isn't really a file extension anyway, as opposed to Windows, where it is. Unix filesystems simply look for the dot ('.') towards the end of the name. And filenames are transportable.

So if one were to utilise the ability of the launch services to recognise file extensions, couldn't ordinary applications do the same?

Imagine, if you will, a system where file extensions were placed in groups where all extensions in the same group were prepared for the same type of on-screen behaviour. Imagine further a system with several behavioural groups for the same application (the same document type). Imagine, if you will, a system where configurations could at least determine (for files that are pure text documents - as a theoretical example):

1. The text alignment - left, right, centred, justified, or 'natural' in accordance with the character encoding used.
2. The document background colour - and let's use only colours that work well with both Apple's light and dark modes.
3. The text font and font size.
4. The document window frame, both x/y and cx/cy (height/width).
5. Whether continuous spell-checking is on, as this is nice in a lot of places but a royal pain when it comes to source code files, for example.

     <key>Configs</key>
     <dict>
         <key>CODE</key>
         <dict>
             <key>Spell</key>
             <false/>
         </dict>
         <key>NOTE</key>
         <dict>
             <key>Bkgnd</key>
             <string>1</string>
             <key>Frame</key>
             <string>1229 572 290 304</string>
             <key>Spell</key>
             <true/>
         </dict>
         <key>TEXT</key>
         <dict>
             <key>Frame</key>
             <string>829 72 590 786</string>
             <key>Spell</key>
             <true/>
         </dict>
     </dict>

And let's conjure up three types of pure text documents to start with.

1. Code files. These are files with source code. They'll want to have left text alignment, a fixed pitch font, spell-checking turned off, and so forth.
2. A type of Post-It file. A sort of 'sticky'. We can call it a 'note'. This might be a small (very very small) window, any font will do, and you might want a different colour.
3. Ordinary text files. These document windows don't need to fill the entire screen. They might actually have to provide room for a web browser window, for example, should the idea be to have two apps working side by side.

     <key>Files</key>
     <dict>
         <key></key>
         <string>TEXT</string>
         <key>c</key>
         <string>CODE</string>
         <key>h</key>
         <string>CODE</string>
         <key>html</key>
         <string>TEXT</string>
         <key>m</key>
         <string>CODE</string>
         <key>note</key>
         <string>NOTE</string>
         <key>plist</key>
         <string>TEXT</string>
         <key>shtml</key>
         <string>TEXT</string>
         <key>utf0</key>
         <string>TEXT</string>
         <key>utf8</key>
         <string>TEXT</string>
     </dict>

That, at any rate, is the idea behind the new Rixedit. And it's leaner and meaner than before.

(Why this is so, and how this is possible, is something even the engineers can't figure out. But it is so, and the new Rixedit's available already a few days back with the ACP.)

So you'd first determine the file extension if any, then search for the extension in a dictionary of file extensions, then take the value found there and search for it in another dictionary of types and configurations.

(Yes it's the same as HKCR except HKCR sorts under HKLM and this is HKCU.)

And then you'd know how to display the window. As regarding Align, Bkgnd, Font, Frame, and Spell. And perhaps, over time, things like - Orient?

(Ten years more and they'll figure out how things grow in all directions.)

typedef NS_ENUM(NSInteger, NSTextLayoutOrientation) {

        // Lines rendered horizontally, grow top to bottom
            NSTextLayoutOrientationHorizontalTopToBottom = 0,

        // Lines rendered vertically, grow right to left
            NSTextLayoutOrientationVerticalRightToLeft = 1,

        // Lines rendered horizontally, grow bottom to top
            NSTextLayoutOrientationHorizontalBottomToTop = 2,

        // Lines rendered vertically, grow left to right
            NSTextLayoutOrientationVerticalLeftToRight = 3,

} NS_ENUM_AVAILABLE(12_0a, 21_0a);

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.