The panel code has so far been resistant to branching because of it's scope. The panel system has multiple pathways at _many_ different levels in a layered design. To truly branch cleanly we'd have to:
– Duplicate the entire panel "stack" (it's a lot of code). Some of those layers may actually be other subsystems in X-Plane .. I'd have to dig in and I'd be petrified as to what I find.
– Then recognize when we are "fast path". This part wouldn't be so bad because we can do the eval at panel-load time.

It is an interesting idea though – code is cheap…could the whole thing just be "cloned off"….

Sorry to go a bit OT, but as to the panel code – branch it. A simple set of radio buttons at the top: Legacy configuration, 9.4 and beyond configuration. One box is ticked and we get the current gobbledegook. Tick the box for 9.4 and up, we get the new slick, clean, well organized command setup interface that leaves the deprecated stuff in the dust. Might be something for X-Plane 10. Heck, you probably thought of this too, at some point!

One or two things:
1. Pricing – it's not GraphSim, it's the big-box retailers – it comes all the way from them! Our distro gets squeezed just like us.

2. Testing windows – Austin _does_ test windows…what he does not do is "smoke test" each build after the final compile. (Since 98% of real dev is done on OS X now, OS X is naturally the "last tested").

Same no-smoke-test goes for Linux…the reason we don't smoke test per build is that the number of per-OS per-build failures that get by _and_ would have been caught in a smoke test is really, really low.

(Sometimes they do get by and we feel like idiots of course. 🙂

I'm not advocating our Q/A process in any way for anyone else or even us. But I can say that when I look at our x-platform bug stats, it doesn't make me say "smoke tests would be a good use of time."

One reason why I think a smoke test wouldn't catch much is that when we do platform-specific work, we do platform-specific testing. But X-Plane is as much x-platform as we can get it to be, to cut dev times down.

3. We untangle architecture of _implementation_ but often not of _interface_. For example, the panel SDK is a nightmare, because it supports so many historical weird combinations of functionality. So far we've dealt with this by suffering, rather than by accelerating the deprecation schedule for those SDK features.

(When people complain that X-Plane breaks compatibility, I think to the time spent making the panel code keep working and fume. 🙂

So basically if the top interface is clean, we can clean out the code…but when we set up an interface that's crazy to start with, we try and try to make the implementation sane but there's only so much you can do.

At least on the graphics side of things I see, the panel code is the only interface that's really out of control, at least that I can think of right now.

That said, I think it an outstanding feature of LR development that keeping the architecture clean is a top priority. Such an approach makes it easy to add coherent new features, and hopefully to debug.

What I think happened, Ben, was that the prose used to describe this was a bit carefree. Given that the beta for 9.3 was going through long teething pains, truly odd behaviours et al at the time, it was natural to blame architectural janitoring for this. Add to the mix Austin's rather ill-advised admission that he never tests his Windows releases, and one touches a match to gasoline fumes. Hence the OT diatribes on LR's internal QA.

Bottom line, though, is you guys are awesome, approachable, reasonable and eminently creative. The brilliance that is in X-Plane is comparable to the sort of thing one sees in high end graphics and development packages, yet Graphsim only allows you to charge $29. Ridiculous, from a fairness standpoint. Insanely good luck for the new user.

I agree with Oli…congrats on all you do, and thanks huge for the continued, inspired development of X-Plane.

Steve

Oli