Angus Thinks…

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.

SQLEditor Cocoa Beta 3 is making good progress. The only things remaining for the current beta are:

• Finish the menu handing
• Write some help

It now pretty much supports importing java version saved files although it’s still having trouble with foreign key support. Which is annoying me a bit but I think the current stage is reasonable to go on with until I can devote a bit more time to it.

Next step is probably to look at implementing more SQL structures and improve compatibility with the standard. I’m particularly interested in developing view support.

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?