Angus Thinks

Author: AngusThinks

  • [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:

    (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/

     

  • 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!)

  • Blockchain isn’t the answer?

    It is important to remember that there are problems for which blockchains are not the correct answer.

  • Tags and Taxonomies

    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.

     

  • Another unbelievable truck advert

    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. 🙁

  • 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 javascript plugins

    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 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)

     

     

  • Raspberry Pi Zero

    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. 🙂