Angus Thinks

Category: Macintosh

  • Runesoft updates games for Lion

    Last year I bought  “Robin Hood: The Legend of Sherwood”; it’s a fun, 3d person, tactical combat game where you play Robin Hood or one of his merry men in the fight against the sheriff of Notingham. When I bought it, it was a PowerPC game and I ran it under Rosetta on my Mac. With the arrival of Lion and the departure of Rosetta, it stopped working and I’d pretty much expected that I wouldn’t be able to play it except by installing 10.6 on a separate partition somewhere.

    However this last week I saw something really surprising; Runesoft has released a patch to bring Intel compatibility to the game and it now works on Lion 🙂

    I’m really impressed with this, thank you Runesoft!

  • Flash player updating on Mac

    Flash Player on the Mac is always in need of an update – or so it seems.
    One particular problem is that the current update checking system seems to merely displays a web page with the current version numbers. That page also appears to contain no direct download links at all. The page it should link to is the Flash download page.

    What it should ideally do is to automatically update using Sparkle or similar. I don’t want it to check constantly in the background, simply check and update when I click the “check Now” button.

    Failing that, it should clearly state whether the current installation is up-to-date or not.
    I don’t want to have to compare version numbers on a page that lists 8 different product version numbers. The software knows which variant it is, its own version number and a web service can be provided to display the latest numbers. It’s trivial to download the latest version number and test to see if it is the same as the installed version, then provide a direct download link if it isn’t.

    In fairness some progress has been made in flash installing, at least they now include a standard pkg installer and progress is being made on providing release notes. But much more progress (or the demise of Flash) is still clearly needed.

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

  • Lion Released

    Lion is released!

    Things seem to be going well. SQLEditor appears to work correctly.

    There is one identified issue which means that you cannot register the app for all users of a machine. Each user must register the app separately in their own account. (This is due to the /Library/Preferences directory now only being writable by root).

    This doesn’t affect Macs which are already registered. Administrators can also manually set the preference keys in the
    /Library/Prefererences/com.malcolmhardie.sqleditor.cocoa.plist
    file to register for all users.

    This problem will probably fixed by making the registration process separate and running it with higher permissions.

    HTMLValidator still needs some more work and isn’t currently compatible. A revised version is in the works and should be available soon.

    TesseractOCR seems to be working fine (and if you haven’t seen them, please check out the xcode 4 source release, it’s a big improvement)

  • SQLEditor and OS X 10.7/Lion

    The release of OS X 10.7 Lion is approaching very fast and the question must be: is SQLEditor compatible?

    The answer is that I expect that SQLEditor will be compatible with OS X 10.7 when it is released in July.

    There is a new page up on the support site about this,

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

  • Mac OS X will still have Java in the future.

    There has been lots of stuff written recently about how Java on the Mac has been deprecated.

    The reality is that one particular Java runtime has been deprecated: the one that Apple write themselves. Java as a language will still be available, only it won’t be Apple that writes it and possibly it might be an optional download.

    The confusion is because up until now there has really been only one Java runtime on the Mac, which Apple wrote themselves using code licensed from Sun. Now Apple has chosen to discontinue their own particular runtime, but this doesn’t mean that there won’t be any Java at all.

    There are already alternatives, in particular the OpenJDK and SoyLatte variants; a little rough in places possibly, but they definitely work. Undoubtably in time they will improve and others will appear, including possibly an Oracle one.

    Obviously it would have been nice to have the deprecation notice and an endorsement of another runtime made at the same time, but given how long it will be until the current runtime becomes unsupported, I’m not terribly concerned.

    Also, whether such a future Java release has a native visual appearance is not of virtal importance. While the Apple Java team has made enormous efforts to get it to look and feel native, it takes quite a bit of work to create an application that looks seamless. The very first version of SQLEditor was a Java Swing application and although it looked fairly good, it was taking too much time making things match exactly. Switching it to a native cocoa application made my life much easier (but killed off any immediate hopes of a Windows version)

    I think most people accept that Java Swing apps don’t look native and will accept that the visual appearance will differ.If you want a truly native feeling Java app in the future you should look at SWT or better Rococoa, not Swing.

    What is important is that future Java runtimes don’t require X11 for Swing. But I’ve seen good progress by several projects towards this goal and I’m not worried about it either.

    Ideally of course, Apple would release their Java Runtime as open source, but whether they are in a position to do that with respect to licensing is unclear.

    Having seen the deprecation notice last week and been somewhat concerned, I’m now fairly confident about the future of Java on the Mac,

  • Apple WWDC videos

    Brilliant work on Apple’s part in releasing all of the WWDC videos to registered developers. In previous years these were only available for a fee (I seem to remember $500), so including them is very nice.

  • Big changes to Mac Developer Program

    Apple have rearranged their Mac developer program so that it now costs only $99 and seems to have only one paid variant rather than the three previously available. (Student, Select, Premier). The online only variant is still available and still free of charge.

    It appears that this is possibly influenced by the amazing success of the iPhone developer program, which is also $99.

    Anything that makes it easier and cheaper for developers to develop applications is probably a good thing. Although obviously you only need this developer program if you need access to pre-releases of Mac OS X and the other benefits it provides. It isn’t now and never has been a required purchase.

    They’re still upgrading the sites as I write this, so I haven’t seen all of the details yet, but definitely looking good.

    [edited to correct information about the free online program]

  • SQLEditor 1.6 final

    So, if you’ve seen SQLEditor recently, you’ll hopefully have seen that there is a new version out: version 1.6. This got released just at the beginning of December 2009

    1.6 is something that I’ve been working on now for a long time, it is essentially (the unreleased) version 1.5 with improvements and updates. In particular it contains a SQL parser that was written using ANTLR and a new JNI based system for using JDBC drivers with support for Java 6 JDBC drivers.

    It’s also the first release version of SQLEditor that is compatible with Snow Leopard. SQLEditor 1.4.7 and earlier had an unusual architecture. When I originally started writing SQLEditor, it was a Java application with a Swing user interface. After some development it seemed clear that java swing was proving limited in some ways. I rewrote the user interface layer in Cocoa, leaving the model layer in Java and using Cocoa Java to connect the two parts together. The application development continued and new versions were released. Eventually though, Apple decided that Cocoa Java was not the future and decided to deprecate it.

    Work began immediately on rewriting the crucial components of SQLEditor, although there were some issues.

    The first was the model code. Every object in an SQLEditor document is represented by an object and all of the code for these objects was written in Java. All of the object code was rewritten and tested against the earlier versions to check that it still worked. It was very important that files from previous versions continued to work (and as far as I know all of them so far do). New code was written to read and write the SQLEditor document xml format.

    The second major issue was that the database interface used JDBC drivers, which are written in Java. Native code would use ODBC drivers. Although similar this might mean that users wouldn’t be able to use existing arrangements to access databases.

    Eventually code was written to bridge between SQLEditor native code and the JDBC drivers using the Java Native Interface (JNI).

    The other crucial problem was the SQL parser. This is used if you paste SQL code into SQLEditor or if you import a file. The SQL parser was written using JavaCC, a parser generator that is written in and produces Java code. Several parser generators were looked at to replace JavaCC and eventually ANTLR was chosen.

    A new SQL parser was written and tested during 2009 in ANTLR and is included in SQLEditor 1.6. The new parser is completely rewritten compared to the one that existed in SQLEditor 1.4.7 and no code is shared between them.

    A major step in developing the new parser was to port all of the SQL test cases from Java (in 1.4.7) to objective C (in 1.6). These automated unit tests are run against the parser to ensure that the new parser behaves correctly compared to both the 1.4.7 parser and the assorted SQL standards.

    It is still something of a work in progress though, there are things it doesn’t support and it’s still being actively worked on. One particular thing that makes this somewhat harder than it might otherwise be is that it must accept SQL in several different dialects, not just a single standard.

    SQLEditor 1.6 also included user interface improvements and various performance fixes.

    Overall it’s an improved program, although I do wish that it had been released sooner.

    Thanks to everyone using SQLEditor for your patience and also for trying the beta versions.