Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Development

ADHOC (formerly famous as MacHack) will happen July 27-31, 2005, in Dearborn MI (near Detroit).

Unfortunately, my plans to publish a paper were foiled by circumstances. My own work has taken me in a different direction – partly motivated by the June Mac-Intel announcement – and my coauthor, the amazing HyperJeff, is very much snowed under by other commitments. So we regret to inform you that we can’t make it this year, but will try again in 2006.

Meanwhile, Dori Smith has several good links to ADHOC information.

One of the joys of programming is that you continually learn new things. So I was prepared to have lots of joy with WebKit. Still, the learning curve seems steeper than I’d estimated, although my comparative cluelessness about DHTML and JavaScript is partially to blame.

Even so, it looks like I’ll be able to do what I wanted. So stay tuned for developments.

Intel debugging

No comments

WWDC was a great opportunity to talk to friends in the flesh and to make contact with Apple people, all of whom were extremely patient and polite.

One of the very last talks I had was with a senior ADC Labs manager (sorry, the name isn’t in my cache just now), who assured me that a couple of months down the road Intel machines will be available at the ADC Compatibility Labs for debugging.

I have just received an e-mail from ADC Labs stating that their equipment is also available for remote debugging over either ssh or Timbuktu, at no charge to Select or Premier developers. So I’ll just have to watch for the new machines to pop up on the equipment list and presto; no need to spring for the Transition Kit.

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.

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…

Re: Tiger, hm

No comments

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…

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2024 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.