I was going to rave again about Brent Simmons’ excellent GUI posts, but Dan Wood beat me to it. (And managed to plug RBSplitView in the same paragraph!) Thanks!
Meanwhile, only one serious bug remains before I release 1.1.3…
I was going to rave again about Brent Simmons’ excellent GUI posts, but Dan Wood beat me to it. (And managed to plug RBSplitView in the same paragraph!) Thanks!
Meanwhile, only one serious bug remains before I release 1.1.3…
Brent Simmons of NetNewsWire fame wrote about Apple’s inconsistent use of split views. I posted some comments there.
In a little over a week I’ll be off to WWDC, so I’ve been busy preparing.
First of all, I’m trying to tame the intricacies of applying WebKit to a purpose not really intended by its designers. The idea is to use it in XRay 2.0 for displaying file info and contents in a more flexible manner. Also, if all goes well, I might take a shot at starting work on an interim XRay 1.2 release in order to learn more about showing Tiger metadata. I want to have at least the broad outlines of both releases working so I can ask people about details.
It’s been hard to disengage a little from my work on RBSplitView, though. The current 1.1.2 version seems to be working well for most people; a few feature requests have come in and I’m slowly working them into a 1.1.3 version, which hopefully will be ready for publication after WWDC.
Brad Miller wrote:
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.
Indeed! One can only hope…
Update: Just FYI, Brad (with help from Andreas Monitzer) was runner-up for the ADA last year, for PulpFiction, in the “Best Use of Mac OS X Technology” category.
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…