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:
- Use overlapping views and hope that nothing serious happens
- Don’t allow views to overlap by restricting the ability of the user to drag them around
- 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.
I had a serious problem with custom sibling views overlapping in my Jigsaw App, but I resolved most of them with a cached image of the views contents and the rest of them with a [self setNeedsDisplay: YES].
The main problem was displaying of shadows, actually.
3 is only a lot of work if you’re thinking of re-doing the code. A few tweaks so that the code is exactly the same, except the drawRect has to be turned into a drawRect atPoint method, and the view is no longer a subview of NSView.
You’re right to avoid 2, and I’d probably go with 1 if I hadn’t had some serious issues with clipping. Notably, shadows would draw permanent lines on other content.
Owl.