A new lego star wars game (new to me anyway, my copy just finished downloading!)
I like what I see so far, the story is exciting, I love the introduction video, it has that “star wars is epic” feel about it.
Flying around is great and the episode 1 pod-race felt really, really fast.
Netflix has been suffering from Disney taking all their content and refusing to play any more.
Still more Korean dramas on Netflix than Disney though…
After a bit of a gap, SQLEditor 4 is now pretty much at the point of a public release.
Thanks to everyone who has been trying beta versions and the most helpful bug reports!
Finished, see the blog post:
🙂
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!
Absolutely awesome art + useful lessons for people trying to improve:
https://www.instagram.com/grizandnorm/
This is the link I was trying to find for L today but couldn’t..
Relieved that I found it 😌
The old Apple Java-dev mailing list and all its archives appear to have been deleted.
The mailman system is reporting “No such list java-dev“
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.
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.
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:
(White)
Dark Mode:
(Gray-ish)
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/
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 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!)
It is important to remember that there are problems for which blockchains are not the correct answer.
When tagging documents with keywords, sometimes too many keywords is as bad as too few.
If you have too few, the document might not be found.
If you have too many, the document will be found every time; even if it isn’t relevant.
Following from the entirely unbelievable but true Epic Split truck advert with Jean-Claude Van Damme,
Scania has offered a new ad, building a working clock using trucks.
I love all of these ads, I really do. But I’m not in the market for a truck. 🙁
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.
There is some new sample code for writing javascript plugins on our shiny new organisation github page:
https://github.com/malcolmhardie-software/SQLitePluginJavascript
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)
The new Raspberry Pi Zero looks amazing!
Base price is just £4!
Sure you have to add stuff like an SD card, a screen and a keyboard. But these can be shared, or borrowed or obtained second hand from somewhere if necessary.
Almost anyone can get one of these and starting building stuff.
It’s going to to be great. 🙂
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)
