Sunday, September 16, 2007

Cocoa, Custom View scrolling

I spent a few hours banging against custom views and scrolling thereof, and learned a number of useful things.

The scenario is a custom view wrapped in a scroll view. Instead of doing the drawing in drawRect: what I'll do instead is manage the layout of my sub-views, specifically a number of NSImageViews. That way I get the drawing for free, all drawRect: needs to do is draw the background (trivial). When my view changes size I can automatically re-layout the images, arranging them into columns and rows.

Handling the resize is a bit tricky. The problem is the frame size of this custom view is semi-independent of the enclosing clip view. When the custom view frame size is larger than the clip view port, you get scrollbars (desired behaviour). When the scroll view grows, you want your custom view to fill up the entire area so you don't end up with weird background drawing.

I played with a bunch of the auto-resizing toggles, but I wasn't able to get things working - for some reason my frame always ended up too tall. So instead, the solution is to ask the enclosing scroll view what the size of their content area is, and size yourself to that. The logic is "make myself the same width, but if I need to be higher to accommodate my images, then be higher, otherwise be the same height as well".

So the first thing is you need to post frame change notifications and register to get view frame notifications... do something like this in initWithFrame: (or maybe awakeFromNib? Apple's docs indicate that initFromFrame: doesn't get called for objects from nibs, but mine got initWithFrame:)

NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector: @selector( frameSizeChanged: )
name: NSViewFrameDidChangeNotification
object: nil];


The problem is you get notifications for nearly every change in the system, but you really only care about if your enclosing scroll view and it's clip view changed, so what you do is:

- (void)frameSizeChanged:(NSNotification*) note
{
id obj = [note object];
if (obj == [self enclosingScrollView] ||
obj == [[self enclosingScrollView] contentView]) {
// change the layout of my subviews
// (accessible via [self subviews])
}
}


The key here is comparing the object the notification is for against your enclosing scroll view, AND it's clip view. If you don't have the second comparison your frame won't handle the start-up quite right.

Now, in your resize handler, you need to figure out the height and width you should set yourself too. Since my goal is to layout images, the minimum you can be is a single column. That way you get horizontal scrollbars when you get too small. Also since I want to display all the images, the view frame height has to be at least as tall as all the images and padding. But, if that isn't quite tall enough, I need to be the same height as my enclosing scrollview or else you get the scrollview background instead of your own (my background is 0.5 white, so problem).

So you need to call:

NSSize newSize = [[self enclosingScrollView] contentSize];

and the later on call [self setFrameSize: newSize]; to set your new height in response to the resizing.

Since I re-layout each re-size the behaviour is I end up with flowing columns of pictures responding to a window resize.

One of the problems I had was the internal bounds origin was at the bottom left corner. The upper right corner would have been more handy, but I adjusted my math accordingly.

Then I had a problem with scroll behaviour - for some reason when the app started it would start scrolled to the bottom. When I stretched the window big then small again, the scroll bar was always at the bottom.

Google solved my problem for me - it turns out that the scrollbar always starts out displaying the origin. To solve both problems just do:

- (BOOL) isFlipped
{
return YES;
}


and both problems are solved. Now image 0 at row,col 0,0 has a origin of (padding,padding).

The basic problem with this approach is the custom view must be the full size of the content area of your scroll-view. If you needed to coexist with other elements inside your scroll view, you would have to adjust accordingly. For example, you might have to not be as wide for a vertical strip, or you might have to adjust your origin of your frame point. Some of the auto-resizing might help here, but I haven't experimented with it.

The view documentation is not the most complete, and there are lots of tips and tricks. There are several approaches too, currently I am using sub-NSImageView instances, but other code I've seen does the drawing straight from NSImage instances instead. That code is more complex, but it may be more efficient since you don't need to instantiate view objects (which can kill performance if there are too many). However it is harder, since NSImageView can draw cool frames for you.

Tuesday, September 11, 2007

Lunch 2.0 At Adobe

Later this month on Friday September the 21st, Adobe is hosting Seattle Lunch 2.0. You may RSVP online.

I'll see you there!

Monday, September 03, 2007

A year later Lego still sucks

What a difference a year doesn't make. I complained last year that Lego Mindstorms software didn't work properly on Intel Macs. Specifically bluetooth doesn't work, due to the non-universal binary. This was pretty sad and pathetic of Lego, seeing how the Mindstorms was released in early 2006, and we knew since early 2005 that Intel Macs were the new hotness. Alas, they weren't paying attention, and anyone on an Intel Mac has a fairly crippled NXT platform. I can tell you, that bluetooth program upload is the super-hotness.

So, a year later, and Lego finally decided to release a point release which also includes Universal binary support. But, wait for it, you have to pay for the privileged of using all the features of your very expensive robotics platform. Furthermore it's very difficult to find even this fact out. It took me about 10 minutes to think to look in the "Need some help" link and be rewarded with the unsavory news.

Lego gets some pretty seriously disses from me for this continuing situation. To be so oblivious to the new millennium and willfully ignorant of a large and growing segment of would be users is not impressive.