SQLEditor Dark Mode Canvas

Recently I’ve been working on providing SQLEditor with a dark mode canvas and here is the current development version (running in dark mode):

This work should hopefully appear in the next beta release.

And of course, with SQLEditor you can choose which option you like, whether light UI with light content, dark UI with light content or now dark UI with dark content.

Coming soon!

Notarization …

Apple is really pushing the whole notarization thing right now.

It does seem a bit like the apocryphal story of boiling the frog, adding small additional restrictions on software freedom each year until the whole platform is under absolute control. (I really, really hope that’s not what’s happening)

At a practical level, I’ve been working away on implementing notarization with SQLEditor, which has caused some issues because of some of the dependencies that are used.

Even the Sparkle application updater requires some tweaking to the signing, which seems surprising, and the bundled Java had some issues too.

10.15 seems to be requiring notarization on newly built apps and I’m hoping to get a better view of the new operating system as soon as I can get the new beta running in a virtual machine. (Maybe Apple could build some virtual machines and save some time here?)

So there’s been a bit of a gap in the release schedule and some of the new work that’s been going on has been delayed. But unfortunately this has to take priority at the moment.

Hopefully I can get this stuff finished soon and work can continue on more interesting things.

Hyper-threading and cleverness

Another day, another attack on processor architectures.

I remember during the computer architecture classes at university marvelling at how clever the processor architectures were. Branch prediction, the challenges of process management and context switching. How everything could be managed so carefully and all the book-keeping kept up-to-date! But it all worked and it worked very well, so I was extremely impressed.

Then when hyper-threading arrived, I was even more impressed. Now I could get most of the benefits of four cores, using only the hardware of two cores.The slight downside was some bits were shared, but this didn’t matter, because it had all been carefully thought through. It was produced by the same kind of people who I had marvelled at previously, and so it was obvious that it was a good thing.

Alas, it seems that hyper-threading (at least on Intel processors) has been over-sold, and doesn’t meet its promise. Data apparently can leak from shared components which, in some applications, is a bad thing.

Since my view must be absolute, I previously adored hyper-threading and now hate it absolutely.

Or, more sensibly, perhaps it’s a case of studying where the risks are and taking the performance boost where the risk can be mitigated and turning off hyper-threading where security is more important.

[NSColor highlightColor] differs in dark mode

I noticed a point today while working on dark mode for Mojave 10.14.

The value of -(NSColor*)highlightColor differs depending on whether you’re in light mode or dark mode.

This particularly affects -(NSColor *)highlightWithLevel:(CGFloat)val;

By calling:

[[NSColor highlightColor] colorUsingColorSpace:[NSColorSpace genericRGBColorSpace]];

I was able to grab the highlight colors in light mode and dark mode. I converted the values to hex and they are displayed below:

Light Mode:


Dark Mode:



Highlight color is noted as for “The virtual light source onscreen”, but it is occasionally suggested for providing slight variations on a drawing color.

Which is great, except that because the output differs between light mode and dark mode, you can’t now use it anywhere within a drawn document unless you want things to look different between the two display appearances.

In the end I replaced the method call with this new code:

NSColor* color = [NSColor redColor];
CGFloat fraction = 0.7;
NSColor* newColor = [aColor blendedColorWithFraction:fraction 
   ofColor:[NSColor colorWithCalibratedWhite:1 alpha:1]];

I also produced a roughly equivalent swift version:

import Cocoa

let color = NSColor.red;
let fraction = 0.7 as CGFloat;
let newColor = color.blended(withFraction: fraction, of: NSColor.init(calibratedWhite: 1, alpha: 1));

print(newColor?.description ?? "invalid color");


See https://developer.apple.com/design/human-interface-guidelines/macos/visual-design/color/


End of 32 bit on Mac will kill off old games

The era of 32 bit Mac applications is probably coming to an end. Apple seems to be moving towards a 64 bit future.

64 bit conversion isn’t very difficult for most ordinary apps, although there will undoubtably be developers who will face severe challenges due to particular circumstances. Apps that include 3rd party code, complicated build systems or involving languages other than C/C++/Objective C are probably at some risk.

But I think most currently sold applications are already 64 bit and have been for years. (SQLEditor went to 64 bit only a while back, without anyone making any comment whatsoever).

The biggest loss though is probably going to be 32 bit only games. Games don’t normally get much in the way of updates anyway, and the likelihood of a new 64 bit conversion is low.

We saw this happen when iOS went to 64bit in iOS 11. Some developers simply couldn’t rewrite their games for 64 bit, for various understandable reasons, so the games are simply going to be removed from sale. One comment was that the particular version of the 3rd party game engine they used did not support 64 bit. To update would require a significant rewrite, not merely a recompilation.

The same also happened with the move from PowerPC to Intel. There are quite a lot of old games that were produced for PowerPC, that were never converted to Intel. Also true  to a lesser extent with the 68k to PowerPC conversion and the Classic to OS X conversion.

Games have essentially been fixed artefacts, they existed in the moment and remained as they were originally sold. Far more so than many applications, where the first release is often merely a promise of some future, better, version. Admittedly games are moving to the regular updates model as well. Often with excellent results like Blizzard with Starcraft, or Introvision’s Prison Architect, both of which have received regular updates and big improvements since launch.

I think the outcome will be that there will be quite a lot of 32 bit Mac games that won’t be playable in the future, and which will never receive updates, which makes me sad. With luck, new games will be released that I can enjoy too, but the loss of old favourites will be a disappointment.

There is one potential silver lining, the desire for all things retro and for remastered editions of old favourites on App stores. The fact that the original will no longer be available for sale may increase the market for a remastered version for newer platforms.

I can but hope 🙂

Github desktop and the tree view

Github desktop has been a helpful companion to my development work for some time now. It’s lightweight, easy to use and integrates nicely with github.com

However there is one neat feature that github desktop v1 had that the newer v2 doesn’t.

The simplified tree view:

I think it’s a really neat piece of user interface because it displays so much information in a small area that would probably otherwise be empty. Yet it’s much simpler than most git tree views, which I find tend to find display too many details. Somehow the information density seems just right, neither too much nor too little. Perhaps it is the Goldilocks of git tree views?

One other interesting observation is that the component was written in javascript, with bits of svg and was particularly designed to work cross platform. Somewhere there is even an article written by the developers, although I can’t find it right now. If you want to understand how the thing works, the whole javascript source is actually shipped inside the v1 app. It’s really very clever.

I appreciate that maybe the app developers are going in other directions, but hopefully they’ll add something like this back into the app. (There is already a bug requesting it!)

Birkhill Fireclay Museum Closed

Sadly it seems that the Birkhill fireclay mine has been permanently closed as a visitor attraction. I was lucky enough to go round the mine tour a few years ago when it was still open and it was a fascinating visit.

The mine had been in operation from the 18th century before closing about 1980. The fire clay that was mined there was made into bricks for use in furnaces, the bricks being particularly suited for the high temperatures involved.

Unfortunately the mine was permanently closed in 2013, after an extended temporary closure. The closure has been blamed on the high costs of maintenance and the poor state of the buildings. I also suspect that the income from visitors couldn’t hope to cover the costs of operating the place, since several people were needed to give guided tours.

So I got to see something that others probably won’t, which is sad.

SQLEditor 3.0 release

SQLEditor 3.0 is ready!

I’ve feel like I’ve been working on this for ages, so I’m really happy that it’s now ready.

The most visible change is the new user interface, which has been merged into a single window. Single window interfaces are something that I wasn’t initially convinced by, I liked palettes and life was good. But since then, I’ve come to see the benefits of the single window. Keeping the panels in a relatively fixed position means that you know where they are. There’s also less busy-work managing the panels.

The tradeoff is obviously that it’s less flexible and on a large screen it can lead to more and larger mouse movements. Feedback has generally been good on this, I don’t think there have been any complaints (so far). If you have an opinion on this please do send in comments!

For me the most interesting new feature is the Javascript plugin system. Export dialects can now be written in Javascript. You can even edit them while SQLEditor is running and see the results immediately.

The new plugin system grew out of the report generating code (also new in 3.0) which was targeting html and using a javascript template language. But then I started looking at this code and realised that there was no reason that export dialects couldn’t be in Javascript as well. The difference between a report and an export is minimal. Both take a data structure and return a string (or possibly a file).

So far all of the built in dialects use native code, but my eventual plan is to convert them to javascript too.

Early code for my own javascript version of the SQLite dialect is already up on Github and further progress is planned for this.

There are lots of other improvements in SQLEditor 3 and I hope to write further about them soon.

Or see for yourself 🙂

SQLEditor 3 Download (58MB zip)



SVG Explanations

Working on SQLEditor SVG improvements (arriving soon in 3.0), and found this excellent series of articles by Sara Soueidnn on several of the details.

So SQLEditor in future will be using the same object icons in SVG as are drawn in the main document and each will be its own beautiful SVG symbol, rather than being separately drawn.

(Object icons in SQLEditor 3 are now little images rather than being individually, because this improves performance quite noticeably and allows nicer styling)

Apple Developer Program improvements

Apple has made some big changes to their developer programs, which I think are a big improvement:

1) You can now apparently develop and deploy to your own iOS device without a program membership. (Possibly only with Xcode 7, I’m not perfectly clear yet). This is a big win for casual developers and people just getting started.

2) There is now a single developer program combining iOS and OS X which is much simpler and cuts the price in half if you subscribe to both

3) The safari extension program is being merged in. This possibly isn’t so great if you were solely doing safari extensions, because now you may need to pay. But if you are doing other development anyway, then it’s a simplified approach (only one program to deal with and remember to renew)

Overall big changes and a strong improvement in most areas.

I’m also hopeful about the new OS versions too.


New Bujold Book!

Wonderful news: Lois McMaster Bujold, one of my favourite authors, has announced a new novel, due sometime in 2016.

If you haven’t read Bujold, I strongly recommend going out, getting a copy of one of them and reading it right now (or you know, when the bookstore or library are next open)

The title will apparently be Gentleman Jole and the Red Queen.

Author Blog Link

Updating wordpress plugins via svn:externals

WordPress usually needs plugins for things, but it’s a pain keeping them updated, unless you want to use the built in auto-updating (which I don’t use for various reasons)

That was until I discovered this method of using svn:externals to update them.[kovshenin.com]

cd public_html/wp-content/
svn propedit svn:externals plugins
<edit as required>
svn update

By adding third party plugins to the plugins directory svn:externals list, they all get updated at the same time as I update the wordpress install, which I already use subversion for anyway. The akismet plugin already gets updated by this method. It also allows changes to the version of the akismet plugin, which is good if it gets updated between major WordPress releases.