Category: Writing Software

Yet again the fact that I’m developing on Mac OS X 10.2.8 is causing problems. Bruce tried out a copy of SQLEditor (Cocoa) on 10.3 (Panther) and it doesn’t seem to work at all. You can’t seem to add objects to the canvas which is the key requirement. Most of the other functionality is based on this particular activity. I’ve looked quite carefully at the code and I really can’t see where the problem is. There isn’t anything odd going on.

This is really bad news, especially after the previous problems that occurred with the java version on 10.3 (which was the reason I wrote a cocoa version in the first place). I’m really not sure what to do.

This has made me a bit depressed because I’ve been working really hard on SQLEditor recently to prepare it for release.

It’s really annoying that there isn’t better compatibility between Mac OS X versions.

I’ll try to write some more about what I’m going to do about this tomorrow.

Punkish made the suggestion in one of the comments (actually the only comment) back on May 29th about adding an actual database to SQLEditor and turning it into a database program. The more I think about this the more I like the idea so it may end up happening. Although it will be a separate program from SQLEditor. SQLEditor will continue as it is because I need it that way for various projects myself.

BTW: The new cocoa version of SQLEditor is about to be released into public beta. Probably either today (Sunday) or tomorrow (Monday).

One thing that is desperately obvious when rewriting a java application to cocoa is overlapping views. In java you can often overlap swing components as long as they are lightweight (not operating system controls for instance). The cocoa documentation says that you shouldn’t overlap view components. This presents something of a problem obviously. How do you make such a significant change?

Currently SQLEditor uses NSViews for it’s onscreen rendering, however since the tables and comments can be freely dragged around there are three possibilities:

1. Use overlapping views and hope that nothing serious happens
2. Don’t allow views to overlap by restricting the ability of the user to drag them around
3. Rewrite the display code to use some other class instead of NSView and render the objects by hand

I’m still thinking about the best way of doing this. (1) is the current solution, I don’t like (2) and (3) looks like lots of work.

I think the best plan is to find out if (1) works on 10.3 and go from there. One approach that I am seriously considering is to rewrite the container class instead and continue to use NSView subclasses for the subcontainers.

David was commenting that drag and drop from the java version of SQLEditor was handy, so it’s returned!
I implemented a new floating window which allows the user to drag and drop objects onto the main canvas. Which seems to work quite well. It doesn’t replace the existing menu options but it provides an easy and intuitive way to add objects. At least I hope it does…

Thanks to Cocoa Menu Validation I now know how to do dynamic enabling and disabling of menu in a tidy way. Previously everything was less tidy and more confused.

Thank you Chris Hanson!

One of the things I’ve been doing recently is to rewrite SQLEditor to use cocoa instead of java’s swing toolkit. This gives a much better application for people using Macintoshes, but it has meant a file format change. The old format relied on java serialization which isn’t possible under cocoa.

The key question is this: are users willing to swap the superior performance and extra features for the hassle of exporting and reimporting their data?