Posted by Brad Miller:
The ADA would be nice. Hopefully what actually happens is that they give you a fat check and replace the piece of #@!%$ that is NSSplitView.
Posted by Brad Miller:
The ADA would be nice. Hopefully what actually happens is that they give you a fat check and replace the piece of #@!%$ that is NSSplitView.
Well, this time it looks like it’s done. All known bugs are gone. I think all weird splitview behaviors in Apple’s applications can now be easily duplicated.
I also added the MIT License, in order to have an OSI-approved license for it. And I’ve entered it into the Apple Design Awards, too. The “Best Use of Open Source” category seemed the best fit, although I’m not using but creating open source here… still, let’s see what happens.
Same place as usual. I really hope this will be stable for some time, at least until after WWDC…
An interesting thing happened while doing this version. (The following discussion will make no sense unless you’re familiar with RBSplitView.)
I have an adjustSubviews method call which does all the heavy lifting, computing the new positions and sizes for all subviews. This worked fine until I saw the need to (sometimes) have a specific subview stay the same size whenever the window was resized. In other words, I needed an adjustSubviewsExcepting: method.
At first I saw no easy way to do this, but then I hit upon a simple trick; I would temporarily set that subview’s minimum and maximum dimensions to the current dimension, call adjustSubviews, then put the original limits back. This was way back in version 1.0.2.
All seemed to work fine until I received a bug report that this could cause the subview to be collapsed in certain circumstances. So this time I tried several ways to prevent this from happening; the code inside adjustSubviewsExcepting: grew ever more large and cumbersome, and nothing appeared to work in all cases.
Then the solution appeared in my sleep (as often happens). The thing was to make adjustSubviewsExcepting: the general case, and adjustSubviews the exception! I already looped twice over the subviews; first, to try to accomodate them just by resizing and limiting some to their constraints, then again if that didn’t work, to collapse or expand some until all constraints were satisfied.
So I added a few lines to double this double loop; once while holding the excepted subview constant (if there was any), then once again while allowing it to resize if a solution was not reached. This proved to work quite well, and I was already near to publishing until I again found a circumstance where it didn’t work.
Turned out my initial implementation was faulty in that 3 passes (not 2!) were needed to find a viable solution. So the algorithm now loops 3 times if there is no excepted subview and 6 if there isn’t. By now, after refactoring the inner loop several times, no serious speed penalty is incurred and everything works much more smoothly.
Moral: refactoring should also consider what is the rule and what the exception…
Whew! I finally succeeded in downloading and installing 8A428, the “Golden Master” build of Tiger (Mac OS X 10.4). So far everything works great. And AAPL also closed up at $37.24… I’m happy.
I was just looking at my user’s version stats – that is, the versions recorded when XRay and Zingg! check for updates – and I’m amazed. Tiger came out officially on April 29th, yet April closed with a 10% adoption rate! And for May so far, late on May 6th, 52% of my users are already running Tiger!
For the record, 4% are still on Jaguar, 35% on 10.3.9, and 9% on other Panther versions. I thought adoption rates would be high, but this is beyond all expectations. It quite confirms my decision to make XRay 2.0 Tiger-only.
Also, RBSplitView 1.1.1 is in final testing and should be out tonight or tomorrow. I’m just polishing the docs right now, so look for it later…
All cat metaphors seem to have been overused already, so I’ll spare you.
If you’re developing for Mac OS X 10.4 (Tiger), or just interested in more technical details, John Siracusa’s review is essential reading. He just about convinced me to make XRay 2 a Tiger-only application. More details on that as the ideas develop… in the meantime, I’ll probably have to do a 1.1.1 bug-fix release on the current version.
Talking of bug-fix releases, RBSplitView 1.1.1 is also in the works… if you have any suggestion or bug reports, send them in soonest.
By the way, Dan Wood just said some nice words about RBSplitView on his own weblog. Thanks, Dan!
Well, it took over a month, but version 1.1 of RBSplitView is now out.
Originally I was calling it 1.0.5, but several people made so many good feature requests it became clear that 1.1 would be more appropriate. Special thanks to Dan Wood, Steve Gehrman and Brad Miller for their input and help with debugging.
When I began coding on XRay 2 some months ago, I ran into severe limitations with Cocoa’s NSSplitView. After a couple of frustrating weeks to make it behave like it should, I began looking for alternatives, to no avail; so I started coding my own version.
Then, as I realized that many other people were having similar problems, and that numerous Apple applications also seemed to have their own handrolled extensions to NSSplitView, I decided to publish my source. It has been a great learning experience.
With my recent decision to attend WWDC, I think the time has come to stop fiddling around with RBSplitView and return to XRay 2, in order to have a working alpha to bug the Apple engineers with. This will be fun!
Yes, I know, it’s been over two weeks. I’ve been holding back some posts I’ve wanted to make, since they demanded preliminary work I couldn’t do at the time… scanning stuff and processing pictures, and so on. Hopefully next week…
Meanwhile, my proposed paper for the 2005 Advanced Developers Hands On Conference has been accepted. ADHOC (formerly famous as MacHack) will happen July 27-31, 2005, in Dearborn MI (near Detroit). A great conference for Mac developers.
Regarding the paper, the working title is: “Out of the Bottle: Beyond the Genie Effect”.
One Cocoa FAQ is how to do the Genie Effect. Unfortunately, the effect itself is done behind the curtain by the Window Manager. We’ll show how to do it in a few easy steps, which will teach you how to:
1) Overlay a transparent window over the screen and draw into it
2) Use OpenGL in that window to move images around
3) Make it appear that your windows are actually doing cool stuff.
Most important, this is the first paper I’ll be doing with a coauthor: Jeff Biggus, the mild-mannered secret identity of HyperJeff (cue applause!). Jeff will be doing the OpenGL part – something about which I know very little right now – and I’ll be doing the graphic interface part. He’ll also attend the conference to present the paper, as I won’t be able to make it this year.
In other news, RBSplitView 1.0.5 is nearly ready for publication. There’s still one feature request and a couple of bugs to take care of, but I hope to have it ready over the weekend. So watch this space…