mikeash.com pyblog/the-mac-toolbox-followup.html commentshttp://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#commentsmikeash.com Recent CommentsFri, 29 Mar 2024 13:16:06 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssAri Weinstein - 2013-02-22 07:47:15http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#commentsGreat article. I have spent very little time with old-style Mac programming, so this was a great little taste. <br /> <br />Re: four-character character literals: <br />I think you're a little off-base here; you can definitely find these in Cocoa, and I've never had a compiler complain about them (though admittedly I probably have only used them in Apple gcc/clang). <br /> <br />For example, you can specify OSTypes with four-character literals. Also they're used extensively in Cocoa's support for Apple Events; types like AEEventClass and DescType are found in NSAppleEventDescriptor, NSAppleEventManager, SBObject, etc. <br />154c27273164fd0cc4b2bcd76b2a5e49Fri, 22 Feb 2013 07:47:15 GMTOwen Shepherd - 2012-02-05 11:08:19http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#commentsThere were, of course, several main concerns in Mac OS Classic which prevented the plain recompliation of all of the code for PowerPC <br /> <br />1) Much of the toolbox was written in 68k assembly <br />2) Much of the toolbox was written in such a way that it had to be shared between all running programsb23c91c96387c8925d77fecbbca1e5b6Sun, 05 Feb 2012 11:08:19 GMTGwynne Raskind - 2012-01-21 19:18:42http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#comments<b>Uli:</b> Thanks for all your corrections! <br /> <br />1) I admit, I've been a little cruel to globals, mostly because I've been bitten by their misuse in the past. <br /> <br />2) The Mixed Mode Manager was extremely clever in making things transparent that way, and I duly salute its ingenuity :). But in my opinion, the extra complexity it added to any code that used callbacks (and there was a <i>lot</i> of such code in the Toolbox) was only a reasonable tradeoff versus recompilation (such as in PPC/Intel) when space limits were considered. <br /> <br />3,4) I'd forgotten about both those bits :). As I mentioned, it's been a <i>long</i> time since I used this stuff, and I only wish I could justify the time it'd take to become proficient again.ad6bf758e0be6ae1e32553571911526dSat, 21 Jan 2012 19:18:42 GMTUli Kusterer - 2012-01-21 07:36:36http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#commentsHi, <br /> <br />&nbsp;another nice installment in the series, thank you! I have a few more corrections: <br /> <br />1) Stop bashing globals. They're the right tool for the right job. [NSApplication sharedApplication] is effectively a struct of globals. It also contains its own gDone-equivalent. <br /> <br />2) One great advantage of UPPs in fat binaries was that they let you mix-and-match emulated 680x0 code and PowerPC code in a single application (something the "Universal Binaries" of the PowerPC/Intel switch didn't support). So you could load a plug-in that is written in 680x0 into a PowerPC app or vice versa. <br /> <br />This is actually what Apple did: They only ported the most important system routines to PowerPC, and everything else still ran in emulation. Then with every system release, more was ported. <br /> <br />3) There is a usability reason that HiliteMenu(0) needed to be called: Menus were supposed to remain highlighted while a menu command was busy doing its work. E.g. if you selected "About" the Apple menu would not un-highlight until you closed the about panel. This was a nice bit of breadcrumbs-style feedback, reminding you where you got a window from. <br /> <br />However, it became problematic when alerts and dialogs started handling the menu bar (originally, you couldn't use menus while a modal dialog was up, not even copy and paste). <br /> <br />4) You should probably add a HiliteWindow() call to the activate event, otherwise your app is going to look really weird. Well, it would, if you had any SelectWindow() calls anywhere that re-order windows on clicks (which also needed to be done manually on content- and title bar clicks).ff8fb5e947113040d2dfa64b0c050263Sat, 21 Jan 2012 07:36:36 GMTGwynne Raskind - 2012-01-20 23:32:18http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#comments<b>Chris:</b> I can only speak for my own experience, and my Toolbox skills were never what I'd call top-rate. I never could have said for certain whether UPPs needed to be saved over time :). Much of the code I used here was partially copy-pasted from multiple ancient projects. As for handling the various other window parts, I can honestly say I simply don't remember how the Appearance-aware Window Manager did things, and how much of the work it took over. <br /> <br /><b>Ken:</b> I didn't know about that document; thanks for the link!f3cdcd5489a22cd102e9026371acf154Fri, 20 Jan 2012 23:32:18 GMTKen Thomases - 2012-01-20 22:59:02http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#commentsMinor quibble: the "open application" event corresponds more closely to the -applicationOpenUntitledFile: application delegate method. In fact, Apple pretty clearly documents how the standard Apple Events are translated into Cocoa: <a href="https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html">https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html</a>36d17fa4df9c8b5a0249e32d1759b33bFri, 20 Jan 2012 22:59:02 GMTChris - 2012-01-20 21:43:42http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">Then you had global variables. Generally frowned upon in any modern program of today, they were all but a requirement for Toolbox development when not using C++ or some other object-oriented language. There was just no other efficient way to get data where it was going. Certainly the global variable for exiting the event loop was a lot better than returning Boolean from every single event handling function in your code on the off chance an action might lead to a Quit.</div></div> <br /> <br />This seems to be a criticsm of procedural programming languages, not the Mac Toolbox, and it's also an incorrect generalization; you are taking poor programming practices that many programs used and extrapolating them to all. There's no good reason to keep the standard AppleEvent handler UPPs as global variables, it's pointless. A boolean for exiting from your event loop ("gDone") can be replaced by any number of superior constructs. <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner"> Handling the zoom box, or the expand/collapse box, or in later versions of the OS, the proxy or toolbar icons, was more trouble than it was worth! </div></div> <br /> <br />Care to elaborate? You got collapse/expand for free unless you asked to handle it specially. The proxy icon was something like an additional inProxyIcon: case, where you then passed the event to a Window Manager function named something like HandleProxyIconEvent(). Not worse than diskEvt handling, surely. <br /> <br />Of course, the Carbon Event Manager eliminated most of this tedium, while still allowing you to hook in at a low level if you needed it.66c9d227bafab25cb8840279f53ba1b1Fri, 20 Jan 2012 21:43:42 GMTjamie - 2012-01-20 18:41:10http://www.mikeash.com/?page=pyblog/the-mac-toolbox-followup.html#commentsI remember having to get into just the tip of this iceberg a few years ago when I started working on Core Audio and Quicktime -- prior to 10.4 you still had to use Handles and FSRefs in order to do simple things like iterate over components. <br /> <br />I think you still have to use FSRefs if you want to write code that does an asynchronous filesystem copy in the background and callsback the client with progress reports (with FSCopyObjectAsync()); also the old Carbon File Manager remains the only way to "set" filesystem comments without ducking into Apple Events or scripting, which work, but have, at best, same-day service.6b3be7b4a63d80b4a8b26c3a6f424f2fFri, 20 Jan 2012 18:41:10 GMT