68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | |
| Today’s the Day: Critical Productivity Enhancement for Finder 6.0-7.x | |
| Posted by: Crutch on 2023-04-16 20:34:00 Okay maybe not critical. But I like it. Drop this in your System Folder so that the Finder under 7.x (and probably 6.x and probably, I think, back much farther than that) will show files modified today or yesterday as “Today” or “Yesterday,” like Mac OS 8 does. (At least, I’ve heard it does. I don’t actually use it.) It’s quick and easy and at least a tiny bit nice. Works in Finder list views and Get Info. It only patches DrawString in the Finder’s application heap so won’t slow down anything else.  | |
| Posted by: nickpunt on 2023-04-19 16:03:29 nice! I love these little usability enhancements to classic MacOS | |
| Posted by: greystash on 2023-04-19 16:56:43 Very cool, Thanks! | |
| Posted by: Crutch on 2023-04-21 06:31:53 Version 1.0.1 now tweaked to be faster and tested to work under System 6 now available on the Garden. Shown here under 6.0.8: Credit where due, I was inspired by this episode of Mac Folklore Radio, wherein Derek reads David Pogue praising Mac OS 8 in part due to this simple feature. Now it’s available in Systems 6/7! https://macfolkloreradio.com/2023/03/03/desktop-critic-mac-os-8.html  | |
| Posted by: MrFahrenheit on 2023-04-21 07:36:57 I'm impressed with modern software written for vintage hardware. Hats off to you! | |
| Posted by: rieSha. on 2023-04-21 14:01:44 Sounds nice! Where’s the 1.0.1 binary version linked? | |
| Posted by: Crutch on 2023-04-21 14:07:34 Ha, I'd forgotten to actually upload the binary ... It's NOW at the garden link above. Thanks @rieSha. ! | |
| Posted by: ymk on 2023-04-21 17:01:47 Great work! | |
| Posted by: pax on 2023-04-22 17:15:04 Wonderful work! Out of curiosity, is it generally "better" to have many small extensions with single features like this, rather than one "big" extension with multiple features that can be turned on/off? Not sure what the definition of "better" would be, but it could be faster boot time, less memory usage, or something else. | |
| Posted by: Crutch on 2023-04-22 18:23:11 Thanks! And your question is on point @pax . Since I’ve written a handful of these little guys, I’ve thought about this too! Just my opinion: If users are likely to use multiple features scattered across various extensions and/or the extensions are pretty small, it’s probably better to combine them into one. For example, most extensions that need to perform an action periodically or on some user action will path SystemEvent. It’s (slightly) slower and less efficient to have a long chain of SystemEvent patches calling each other across multiple extensions than to just have a single, integrated patch. To your point, loading multiple extensions also definitely slows boot time. Larger or more complicated extensions should probably be separated, since otherwise their patches will slow execution (a tiny bit) and the patch code will (for sure) take up RAM if that code is installed as part of a larger extension, even if the particular feature it implements is turned “Off” in a control panel etc. (There are ways to write an extension to unload parts of itself when turned off, but it’s [I would expect - never actually done this] liable to be cumbersome and liable to introduce bugs, and anyway extensions are supposed to be pretty small.) At some point I’d like to combine a few of the little extensions I’ve written into a single bigger one, but doing so also complicates the code a little. | |
| Posted by: pax on 2023-04-22 20:01:32 Makes sense, thanks @Crutch! | |
| 1 |