Angus Thinks

Category: Writing Software

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

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

     

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

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

     

     

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

     

  • Webkit Javascript Optimizing JIT compiler(s)

    Is your JIT compiled javascript function running too slow?
    No worries, just wait and the javascript engine will recompile it and then replace the function with a faster version!

    But that’s not fast enough either?
    Webkit will compile another version using more optimizations, using code from LLVM.

    Is the function still executing some long running loop?
    No problem! The javascript engine will copy all of the current state and build a new compiled function that starts at the beginning of that loop, then replace the old slower function with the new one, while it is still running!
    It gets flipped over at the beginning of the next run through the loop.
    (see the Hot-Loop Transfer section of the original article)

    Just from the description, this sounds stupendously complicated. But the performance improvements are apparently quite considerable.

    I’m truly impressed by the effort that goes in and the work that’s been done on this.

    🙂

    Read the original post for the full details:
    https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

     

  • Using NSDockTile for debug info

    Often when I’m working on an app or something I end up running several different versions of it in a short period of time. There’s usually some bug that I’m trying to fix and I want to make sure that the bug occurs in the old version and doesn’t occur in the new version.

    Sometimes though I get confused which version I’m running. Is the app in the dock the old version, or the new version or something else?

    So today I had an idea: Why not put the version number on the dock tile?

    Here’s the code to do it:

    if (DEBUG) {
  id badgeText = [NSString stringWithFormat:@"D-%@",[[[NSBundle mainBundle] infoDictionary] valueForKey:@"CFBundleVersion"]];
  [[NSApp dockTile] setBadgeLabel:badgeText];
}

    This assumes that you’ve got DEBUG defined somehow and that you have an infoDictionary with the relevant keys and values set.

    And here’s what it looks like in the dock:

    Regular version on the left, development version on the right.

    I’m not sure how useful this will actually be, but it seemed a handy trick for development.

  • SQLEditor upgrades

    One of the big questions I’ve been thinking about recently is how to price upgrades for SQLEditor. So far upgrades have all been free as 1.0 became 1.1 and eventually 1.7. But with the new 2.0 release appearing soon, the question is what should be charged.

    Personally I’ve been annoyed with products where I paid money and a new release appears two weeks later which requires a paid upgrade. On the other hand, SQLEditor 2.0 will be a considerable upgrade from SQLEditor 1.0 (the first paid version), so I do think some additional fee is justified to fund development efforts.

    But obviously I don’t want people who haven’t bought yet to have doubts as to whether they will be required to pay for the upgrade.

    The stated policy is that anyone who bought SQLEditor within 12 months of a paid upgrade being released gets a free upgrade.

    However given that the release date for the new version hasn’t been decided yet, I’ve decided to improve the arrangements for version 2.0:

    Customers who bought SQLEditor 1.x after August 1st 2010 will get a free upgrade to SQLEditor 2.0.

    This means that if you buy SQLEditor today you get 1.7.8 and when 2.0 is released you would get an upgrade to it free of charge.

     

  • Xcode 4 – Great!

    Xcode 4 took a little while to get used to, but as I’ve been using it more, I’ve been liking it more.

    The change initially is significant, and there were new ways of doing things and certain other things that had to be rethought altogether. But now, I’m starting to choose to use Xcode 4 when I have the choice, so I think I’ve got used to it

    I recently released some new project files for Tesseract OCR cocoa, and they are built with Xcode 4 now. The simplification in the build system and the linking of the frameworks is a vast improvement. Workspaces are a gift to this type of multi-project build. 🙂

    The only issue I have is that it doesn’t support 10.5 or PPC, so SQLEditor is stuck on Xcode 3 for a while longer.

  • SQLEditor now zip file not a dmg

    In a change that will probably affect almost nobody at all, SQLEditor is now being distributed with a zip file rather than a dmg as the default download.

    Why?

    • Zip files are simpler to create
    • It prevents the problem of the app being run from the dmg
    • Safari handles zip downloads really nicely
    • Disk images created in 10.6 tend to loose their background images in 10.5

    That last problem is quite significant, because most of the friendliness of the dmg is the background image; if you loose that, you might as well have a zip file.

    There are some benefits from dmg files:

    • They have the background image and the drag to applications directory install
    • DMG files can be smaller
    • DMG files are handy to store

    But then if you loose the first point anyway, it might not be worth bothering.

    Now there are excellent tools like DMG Canvas for creating cross platform disk images that work fine and keep their background images, but I began to wonder if it was worth the effort for SQLEditor. Were the benefits of the background image sufficient to make up for the trouble?

    Various notables including John Gruber, Panic and Sofa recommend or use zip files, so it’s becoming more popular. (The Mac App Store uses pkg but it’s a different story altogether)

    The change isn’t actually as significant as it seems anyway, because SQLEditor has been available in both zip and dmg formats for some months now. The release process automatically builds both zip and dmg format archives and uploads them at the end of the build release process. The change is really just that the website links now point to the zip instead of the dmg. (And if you really want the dmg you can change zip to dmg in the download link and get a dmg)

    Enjoy!

    Or take absolutely no notice of it at all 🙂