Download Links at the Bottom

From the ACP/Xfile update 18 March 2017.

Get It Try It

No announced updates. Just a few words. But download links at the bottom.

*

We who still use computers rather than mobile devices have a problem. This problem is not shared by the industry in general. IBM is going strong, Microsoft is born again under better leadership, mainframes still exist, web servers abound.

But Apple no longer have a division for computer software development. Updates there accrue from things happening in their mobile division. This is a sea change.

Tim Cook has asked why people even need computers anymore.

Financially for Apple, that's not hard to understand. A full two thirds of their revenues come from iPhone sales. iPhone doesn't dominate the mobile sector. Android does. But Apple still sit at the top with the biggest market cap.

Go figure.

I want you to try to understand what this means from a programmer's perspective. The freedom to tinker is threatened. Without that freedom, nothing is fun anymore. Trying to develop for a mobile device is not fun. It can be lucrative for big corporations who can pump massive amounts of plumbers pipe into development, but those poor sods won't be happy campers. Their jobs are humdrum 9-5 with eyes on the clock at all times. It's no longer a calling or artistry. It's just a job.

You can't develop on the platform you target. You have to run your app through a simulator. You might as well write device drivers. And that's about as antisocial as you can get. It's simply not fun.

And that's not even getting into the 'walled garden' nonsense. Code-signing is bullshit. We don't need it for protection - we already have the safest platform going! If you don't get it: code-signing is so Apple can choke the industry. It's not just their 30% 'tribute' - it's that the 'model' doesn't work, and crushes the integrity of the independent software developer.

[RANT: And yet you know that the clueless end-(l)user doesn't see this. Apple's 'App Store' is a DESKTOP APPLICATION. It can't get better. AOL and Microsoft fought over desktop real estate. We've developed apps for companies so they can get presence on the desktop. Apple's 'App Store' represents a presence that ruins the industry. It's an offence - an effrontery. Whatever.]

I'm looking at our own Mac fleet. There's Syd's original iBook. Bad design, so she had to research how to fix the screen. They put the cable in the hinge FFS. She spent a lot of time researching, then cautiously took the box apart on our little green table in our house in Kolimbari - and actually succeeded! But then the battery swelled...

So I bought her a MacBook. That battery too began to swell.

My first TiBook. Great design. Forget the titanium - why the graphite? We saw lots of them at the reseller in North Carolina. All smudged. Ugly.

Then the hinge even there. Torque. It breaks. Hooray.

Then a succession of what Syd called ANALBooks. It was ANodised ALuminium, but the fanboys understood what was coming, so they quickly dubbed it the ALBook. Great.

The first AnalBook? Sony battery recall. The 2nd AnalBook? THREE batteries. ALL SWELLED.

In between, we got another AnalBook, brand new, that was DEAD ON ARRIVAL. It just kept rebooting all the time. Had to send back. Canceled order.

Then came Unibody. Suddenly things were better. We somehow missed the thermal grease scandal. And paying $250 extra for a black coat of paint. The unibodies were good.

Then Apple updated with the TOUCH BAR. And prices skyrocketed. And even the old unibody without the touch bar went up $500 just like that.

Go back to desktops? To what? When last have they had a decent desktop anyway?

So we'd like new MBPs, but where to get them? Microsoft came out with the magnificent Surface Studio, they're in the hardware business now, but their laptops look like shit, and they still run W*nd*ws...

Objective-C is the shizzle. Anyone who knows what they're doing - really doing - understands this. So why 'Swift'? Swift is unnecessary. And it really sucks. But still worse: it adds a link overhead of 30-50% to a binary even if the language is not used.

Get that.

We have an antiquated 10.7 box. This is absolutely essential, as it can run an older version of the LLVM compiler, which superseded the GCC compiler, and can produce 'adult' binaries.

But there's more.

Somewhere between 10.7 and 10.12, as Jony Ive was thinking up new ways to make Apple laptops even thinner, he pushed into software, ousting the man who gave Apple their iPhone. And now graphics would be redesigned too.

The crucial change here was in tableview headers. They're 6 pixels higher.

Now most tossers don't give a hoot about that, BUT WE DO. All our tableviews are to be 'tidy' and show an intelligent number of rows without scrolling. Up to and including builds prior to 10.12, they all did. Starting with builds for 10.12, they all need 6 pixels more.

There's problems here, updating software from one platform to the other, and then testing on both the current 10.12 and earlier versions, as we don't know you're all on 10.12, and in fact know that many of you are not.

We've tried to make both versions work as designed, but something got mixed up, and some tableviews are screwy again. So we need a methodology to take care of this in the future. For now, let's assume we can do that.

Next biggie: the new 'mail core'.

Apple removed support for third-party SMTP. Yes, it's true. They're so paranoid about people getting mail out that they removed a great framework. Developers asked 'WTF' and were told 'use a script with Apple's Mail.app'. SRSLY. The framework's been deprecated for some time, and now finally it's gone. It must be replaced.

SMTP is not that difficult. We did it manually in our rewrite of Hobbit's netcat. But we'd rather use tested modules. But finding a replacement has not been easy, and we've been testing candidates for a long time.

The latest one looked REALLY GOOD - except its key header file MailCore.h is missing from the Git distro! Go figure. ;)

So I don't know how this will resolve, but I consider it key. It sounds like a sine qua non that you can get out of your computer without Apple, doesn't it? ;)

Next item. Toolbars.

We spent a long time looking into emulating Apple's 'new groovy' toolbar look. This is complex, over and above the original MO. All our apps used the original MO. The new method involved itemising toolbar items in the NIB itself. This can perhaps cut back on binary footprints, but it involves more coordination, more work, etc, and these apps already exist.

Then we have to go into each and every node in each NIB and redeclare each toolbar item in a funky way to get the desired size and effect. This in itself is no biggie.

Finally, we'd have to dream up new glyphs for all the location items we use today. Here's where the 'Recognition Principle' comes into play.

For those who don't know - and most of you won't - there's a set of VERY WISE standards outlined by IBM long ago, before the age of grotto paintings. They're part of what's known as 'SAA/CUA' - Systems Application Architecture / Common User Access'. The reason Big Blue spent so much time on this standard was that they'd acquired so many hardware variants and user interfaces that they needed to get thing organised. And in so doing, they had to do very basic work in the elements of interface design. Microsoft's 'CUI' ('Consistent User Interface') and Apple's HI Guidelines are both based on SAA/CUA.

The SAA/CUA is some smart stuff. There's the 'User in Control Principle', for example, which is why we see hourglasses and spinning beach balls. Then there's the 'Recognition Principle'.

The ideal implementation of the 'Recognition Principle' is when you sit down to a new application you've never seen before and everything seems self-explanatory. There once was a system like that - Onyx from Interactive Systems in Santa Monica. It was brilliant. IBM got them to make their PC/IX, which was a short-lived Unix. They also had 'ined', which was their text editor for Unix, and it was absolutely brilliant, the inspiration for our own work on MS-DOS back in the day, and as well to some extent our later work with Windows, early Unix systems, and OS X.

All menu items have to be at expected locations. Layouts have to be familiar. Most importantly: toolbar glyphs SHOULD BE STANDARD.

Up to now, whether they were used often or not, Apple always had standard location images in the system. *That's what we're using in Xfile*. They don't have them anymore. So we'd have to get some graphics genius to create new images that were NOT standard to fit into a much smaller space - and people would have to immediately recognise them. Uh - no, it doesn't work.

Then too, a sober moment: Apple can (and will) change that look at any time. Respectable OS providers never engage in things like that. They only provide the OS, and make the OS as perfect as possible. But Apple don't do that. Otherwise we'd have had a perfect OS twenty years ago. (And FreeBSD is as perfect as we have a right to demand.)

Apple want to provide hermetically sealed systems from Planet Groovy(tm). They'd rather there were no ISV products at all. Traditionally they treat 3rd party companies like shit, and we're all lucky we fare a bit better today. The introduction of Unix had something to do with this, but Apple keep trying to kill off the 'Unix' in their systems, and, after all, 'XNU' - 'X is Not Unix'.

Given this stacked deck, then there is no reason to play 'catch up' with Apple. That's a 'Cabel' idea. It's wasteful and futile. So we stick to the rules - to the standards. And let the others scramble in a panic. Remember how 'drawers' were all the rage? And black popups? Our old friend Sargon (RIP) would have told us to 'GTFO' at the mere suggestion we give in to such a temptation.

Next thing. Tags.

Sorting through an XD can be a bitch. I've discovered this as I accumulated tens of thousands of files. As I was laid up for so long, and prevented from getting into the office as a result, I had quite a lot of time to think through this (and precious little else - it kept me busy).

As I remember it, I was laid up for about one year ten months. I went through at least three different designs in this time, and each of them foundered at the end, with at least one important piece of the puzzle missing. These initial designs involved at least three sovereign applications each. But they failed.

I finally got it right about one year ten months later. The solution is a hybrid of Xfile and Xscan. You have the prototype now - it's called 'Rixtag'.

OK, a few unnecessary words about the name. I can't remember what this started as, but I remember 'Tagways', 'Tagwise', 'Tagger', and 'Xtag'. And we were at 'Xtag' when we realised Apple no longer use 'X' in their OS name. 'Rixtag' is at least neutral.

Here's where we're not neutral: we have our own tag system. We use the name 'com.rixstep.Rixtag' for an XA in the form of an XML property list that's an ARRAY of text strings. The overhead for extracting these XAs and strings is not harmful.

Now we know that Apple have been thinking along the same lines. They too have an XA that can be used. The problem here is they have no way to manage their tags.

We can provide it.

We can add a setting so our tag manager (Rixtag) can search for different XA names. That should be easy to do.

The tricky part is to not only scan for tags (which works already) but to MANAGE them.

The basic idea (the basic model) is Gmail. There's a lot of thought that went into Gmail. First is the realisation that there's been an unexploited field in email headers. (That's genius.) Then there's their use of labels rather than folders. (That's the bitch.)

For our part, we still have to find a way to let you click any tag name on the left and IMMEDIATELY get a list on the right of all pertinent files. YES, we could make an implementation tomorrow which gave you that listing 'sooner or later' but we want the rendering to effectively be INSTANTANEOUS.

So I'm working on a dynamic model. If teh Googels can do it, we can!

The model will most likely include (some pieces are already in place) a hierarchical dynamic array structure. As each new tag is encountered, it enters into a volatile array, and its value becomes the file data for the path encountered (no recalculating this later) or perhaps (we don't know yet) a pointer to the tableview source's row itself. This is going to be tricky to say the least, and there's otherwise been too much to do for the moment, sorry!

Next. Your suggestions.

This can be difficult. But good ideas do come out of random exchanges. So we put it out there as always. We're looking for 'gaps' - essential things that are missing. Got an idea?

The last? What we do now.

1. Renewals.

We suspended these whilst I was sick. No point in paying to renew our agreement when there's no new software. We've had a few updates since, but not enough for my liking. We need to get fully on the rails again to justify that.

2. Priorities.

A. The development model here.

We'll start by cleaning up our NIBs for 10.12 and earlier distros. If you use an earlier distro, and something doesn't look right for you, or work right for you, contact us.

B. Mail Core, Rixtag.

C. New cryptographic model for CLIX.

Not mentioned before, but we're working on this too. We'll publish details on the whole shebang at that time, and we'll release the corresponding 'free' version as well.

D. The future.

We all have to decide if we're going to stay on this platform.

*

Postscript
----------

In case it's not patently clear:

- We will never cooperate with Apple's 'App Store'.

Kthx.

See Also
Xfile: Free Test Drive
CLIX: Learn How to Fish