Centering a documentView inside an NSScrollView

This took me a while to sort out, but I finally figured it out.

Basically if you want to have the documentView of a NSScrollView be centered in the view if the content area of the NSScrollView is bigger than the size of the document view, you would override the NSClipView class with a custom class. This class would then implement the -constrainBoundsRect: method as follows:

@implementation GClipView

- (NSRect)constrainBoundsRect:(NSRect)proposed
	NSRect r = [super constrainBoundsRect:proposed];
	NSRect doc = [self.documentView frame];

	if (proposed.size.width > doc.size.width) {
		r.origin.x = floor((doc.size.width - proposed.size.width)/2);
	if (proposed.size.height > doc.size.height) {
		r.origin.y = floor((doc.size.height - proposed.size.height)/2);

	return r;


This may not be good.

When you’re building an example UI for an Arduino, you have two screens to finish, and you see something like this:


Sketch uses 31424 bytes (97%) of program storage space. Maximum is 32256 bytes.
Global variables use 692 bytes (33%) of dynamic memory, leaving 1356 bytes for local variables. Maximum is 2048 bytes.

So let’s see if I can’t write the code for two screens in 832 bytes…

The Hacking Den.

So I’ve started a new blog at The Hacking Den, and I’ve included a number of posts there.

While my comments here on Chaos In Motion have generally been technology oriented and more commentary about technological ideas, The Hacking Den is intended to be a more practical hands-on learning site.

I figure it will take a few months to find my voice, and I do have a number of plans for that site, including doing video animations a’la 3 Blue 1 Brown, an fantastic site for math visualizations. My intent, however, is to use the same sort of visualizations combined with hands-on coding and hardware construction to teach a variety of topics in Computer Science, ranging from the mundane (such as constructing a 3D rendering engine for an Arduino, or teaching computer programming or user interface design, or even constructing hardware projects) to the more abstract (such as visualizing different computer algorithms).

Right now I’m concentrating on a few topics which have been of great interest to me: building an Orrery, a mechanical model of the solar system which calculates the relative position of the planets mechanically, and illustrating the principles of user interface design by building software for an Arduino equipped with a touch-screen.

Stop by and visit the new site and let me know what you think!

Well, that’s a couple of hours I won’t get back.

So today’s mission: while working on a Mac app, I wanted the correct icon to show up for my documents.

And of course that involved a lot of hair pulling.

Here’s the answer.

(1) Create your document icon. Open the Assets.xcassets, right click on the icon list, and create a new MacOS Generic Icon. (Under “App Icons and Launch Images”.) Create your document icon in the resulting icon, renaming as appropriate. (In my case, I named it “DocIcon.”)

(2) On Xcode 9.4, if you open the project file, select “Info” and show the Document Types, the “Icon” drop down does not show the contents of the Assets catalog for your icon. Xcode lies!

Just type the Assets icon name into the drop-down. You’ll continue to see a question mark. Don’t sweat it.

XCode Document Setting

(3) There is no step 3.

Now of course if you want to allow other apps to play in your background, you can also export a UTI. Notice how I defined an “Identifier” above? Well, if you don’t export a UTI this won’t work; leave “Identifier” as blank.

However, if you want to tell the OS that your file is a type of another file–like, for example, your file can be opened as a text file, then define your UTI identifier (using the com.blahblahblah style for UTIs), and add an exported UTI:

Extern UTI

This basically says “hey, MacOS, that UTI type “com.chaosinmotion.Kythera.gearfile” I told you about? Yeah, it’s also a “public.text” text file.

And you can also import UTI types; that basically tells the system “hey, I can open public.text files!” But that’s beyond the scope of stuff I care about right now.

The things you learn along the way to trying to design your own computer language.

So here are two things I sort of uncovered on the path towards designing my own computer language.

(1) Do you have headers or not?

Meaning is your computer language one that includes headers and some sort of mechanism for loading those headers? If so, then a few things become true:

You implicitly need two ways to define something: as an include or forward declaration, and as a concrete definition.

That implies you need some way to say in your header that “Foo” is a function and “Bar” is a global variable, but don’t define “Foo” or “Bar” here. If your language is object-oriented, you then need a way to say (as Objective C does) “@interface” and “@implementation”, and (if your object-oriented language has single inheritance with interfaces or protocols) “@protocol”.

Note that in Java, you only have ‘class’ and ‘interface’; ‘class’ also doubles as a way to say “somewhere this class is defined, but I’m not defining it here.” But then, Java doesn’t have include files.

How do your include files work? That is, are they loaded by a preprocessor into a single logical file, as in C or C++? Or are they separate “definition” files which are compiled then referred to during the compilation of your source code?

This can also implicitly work with precompiled headers, but I’m thinking of a header language which is orthogonal to the source language. Meaning you could theoretically design a language where the headers can only legally include stuff like “extern int foo();”, but cannot legally contain:

int foo()
    return 5;

Now if you don’t have headers, you need to figure out how to handle precompiling enough information from all of your source files so you can refer to the signature of your objects from other files. That could be done, for example, through a two-pass compilation process: the first compiler pass only constructs the implicit header information (the names of globals, functions, classes, methods), then the second pass actually constructs the code, including other class declarations as required.

(2) Is your language strongly types or weakly typed?

One consequence of a strongly-typed language is that every expression in your language, you know the type of the inputs and the implicit type of the output. You know, for example, your variables ‘a’ and ‘b’ are integers, and thus the result of addition will be an integer. You know if you have different variables types for ‘a’ and ‘b’ (say, ‘a’ is an integer and ‘b’ is a real number), then your compiler has to implicitly handle the conversion of a to a real number prior to addition, and the result os a real number.

This puts a lot of things on your compiler. You need a type representation which can represent all the types (including compound types) of your language, so you can differentiate between int **a and int *a, and so you know the result of dereferencing a variable.

On the other hand, if you have a weakly typed language–any variable can be pretty much any value–then this makes the design of the compiler far simpler. But it makes your run-time engine do a lot more work: because a can be anything and b can be anything, the variables have to have an implicit type associated with them, and you your addition code has to know how to add any two objects together to get a reasonable result.

Of course weakly typed languages result in some weirdness; just see the various examples about addition of integers and strings in Javascript.

I’m sure I’ll learn more things along the way. But these are the two that have bitten me in the past few weeks.

If you’re using iOS or Android notifications to push ads, I’m turning your notifications off.

Notifications are not an ad channel. They’re a method for pushing notifications to users that require action, such as informing you of new messages or of issues that require action on your part.

And your damned ad is not my urgent issue that requires action.

I’m looking at you, Amazon Kindle, and you, app…

I think my biggest problem is that no-one really knows how to do design anymore.

Design Plagiarism

In this case Savov was writing about Huawei’s copycat wireless earbuds. But the most telling example — which Savov himself has documented better than anyone else — is the iPhone X notch. The notch is unquestionably the worst thing about the iPhone X design — it is a worthwhile compromise, but a severe and glaring one. But it lends the iPhone X a distinctive look and can be easily copied, and so of course these companies are shamelessly copying it. Anything they can copy from a successful Apple product, they do. (How many PC laptops look like MacBooks?)

Here’s the problem I have with all of this: no-one designs from the ground up anymore. It’s all copying designs and marketing and strategy–without any real understanding of why the compromises or the reasons for the design decisions.

Now it’s not surprising that Chinese companies blatantly copy Apple. The whole point is for people to walk around with devices that look like the elite leader without paying elite leader prices.

But so much design done by various companies ripping off each other have no fucking idea the first principles of design.

Meaning I don’t care if one company implements the functions and features from another device. But if you don’t have an understanding of the way information flows between screens, the concepts behind affordances and giving rapid and timely feedback to users, to concepts such as the magical number 7, and other design issues like giving users feedback for processes that take longer than 1/4th of a second to complete and a way to cancel operations that take longer than a second–then the best you can do is make a very piss poor copy.

It’s all cargo cult development.

And the user suffers as a result.

The sad part is that many of these companies would be better off forging their own direction, copying concepts from the 1990’s, than copying from Apple without understanding why those design decisions were made.

OCYacc/OCLex announcements

I currently have been tinkering with a compiler tool which provides Yacc and Lex-like functionality (with an LR(1) compiler parser) in the OCYacc/OCLex tools.

Basically I needed a version of yacc and lex which could build a compiler, but generate a re-entrant Objective-C class.

Well, recently I’ve been adding a code generator to generate C++ code. It’s still pretty experimental, but the code is now checked into GitHub. Check it out.

More information can be found here.

When working on a large project, take the time to document the internals.

So I’m working on a very large project which I intend to discuss elsewhere at a later date. But it involves a lot of code–and is quite easily the largest thing I’ve ever considered taking on to date.

And I find I go for a few weeks making serious headway–then find myself spending less and less time coding and more and more time surfing the web. I think it’s because I’ve hit a roadblock; the project has gotten so large I can no longer see the forest for the trees. (And hell, at the level some of this code exists, I can’t see the damned trees for the individual leaves.)

I’ve discovered a secret, however.


When I start forgetting what’s there, it’s good to stop at a good stopping point, and take a survey of what’s there. Nothing fancy; just a simple iteration of what’s where at a directory level helps worlds to get your bearings.

Because otherwise, it’s easy to get lost when you’re looking at several months worth of work, with over a hundred source files and tens of thousands of lines of code, wondering “what’s next.”

And in the documentation you even find things that perhaps you forgot to deal with. Corner cases you thought “I’ll deal with you tomorrow”–only for tomorrow to never come.

So today’s a documentation day. It’s healthy because it reminds me of what I’ve done. It also reminds me of what I still need to do. And it reminds me of things I could do in the future.