On 14 Feb 2017, at 22:15, Graham Cox <graham....@bigpond.com> wrote: > >> On 15 Feb 2017, at 12:39 AM, Andreas Falkenhahn <andr...@falkenhahn.com> >> wrote: >> >> I knew how to use IB on the old PowerPC Mac, >> but that was 10 years ago. > > Well, it hasn’t changed that much in principle. In fact it’s got a lot better > in most respects because it stays in sync with your code and is not a > separate app. Some things are worse though, like the pick list for UI > elements, which makes you do a lot of scrolling to get to the one you want.
Personally I preferred it as a separate app; the “staying in sync with your code” part wasn’t such a huge problem in practice and could probably have been fixed without integrating it (which, particularly because it went single-window, forces people to use Xcode as their editor). I also liked having the separate window for the nib file structure - the side bar can get quite cluttered in more complicated nibs. But I’m not going to turn this into a critique of Xcode design decisions. > Now I'm trying to compile this old project on a >> 10.12 system with the latest Xcode but somehow the project was messed up by >> Xcode when converting it from the old format to the new one and now it >> shows weird issues. > > So it messed up. That’s annoying, but should be fixable by spending half an > hour in IB to identify and fix the broken connectins (or whatever). You will also need to check API behaviour. Cocoa behaves quite differently in some places depending on the system version and Xcode version used to build code; I’m not sure if there’s a list of all of these places anywhere - it’d be quite useful for this kind of situation. (Formatters in particular have rather different behaviour.) When I first saw Apple doing this, I thought it was a good idea. I now think otherwise. It should have based behaviour changes on a separate API level setting, which would have meant Xcode could issue warnings when an API level stopped being supported so that you’d know what to focus on. I know we’ve managed to ship bugs on a couple of occasions because of API behaviour changes that we didn’t appreciate or spot; thankfully these have tended to be cosmetic (e.g. percentages were being formatted incorrectly), but it’s still worth checking *everything*. > Of course, I could just dump the old project and start a new one with the >> latest Xcode, re-creating everything from scratch. But do you really think >> that is a satisfactory solution? > > It isn’t the ideal solution, but sometimes you are faced with hard choices. > > One problem sounds like you’ve put a lot of interfaces into one nib file, so > that’s going to make life harder than necessary, That isn’t a big problem in practice. iDefrag and iPartition have quite a few things in a single main nib file that would probably be split out into multiple nibs in a more modern code base; I’ve had no reason to change that (they don’t use window controllers or view controllers, so it just isn’t a problem). > and another is that you’ve gone against the usual conventions with menu > actions and targets, so that’s going to make life harder than necessary. [snip] > The obvious thing to me was to get into IB and start figuring out the > problem. Instead you ranted about how much of a time sink it was being > because IB was different and you’d forgotten how to use it. Not only that but > the way your project is organised is unconventional, to say the least. If you > prefer to swim upstream, you only have yourself to blame. To be fair to Andreas, the stream has changed direction somewhat over the years, and I’d be lying if I said I’d never found updating projects to be compatible with the new version of Xcode I was forced to use because of OS compatibility issues was not an annoyance. (Indeed, the last round of Xcode’s automatic project upgrades caused yet another problem, this time with code signing.) Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
