[HN Gopher] Stapler: I remade a 32 year old classic Macintosh app
       ___________________________________________________________________
        
       Stapler: I remade a 32 year old classic Macintosh app
        
       Author : msephton
       Score  : 193 points
       Date   : 2024-08-10 21:03 UTC (1 days ago)
        
 (HTM) web link (blog.gingerbeardman.com)
 (TXT) w3m dump (blog.gingerbeardman.com)
        
       | samstave wrote:
       | This is cool.
       | 
       | I've had a desire for something like this (windows/linux) -- what
       | would be cool is if it knew the window size and layouts?
       | 
       | So you could do a launch group that will do the whole desktops
       | workspace - and can be saved (but also has a reset button to snap
       | back to the layout if you mix things up. Support for a second
       | desktop to launch then to - so you can throw one context cluster
       | on each...)
       | 
       | ---
       | 
       | Weren't you the one who lost all their archive content? What was
       | the timeline with all of that?
        
         | msephton wrote:
         | If you quit and relaunch the app with windows open it will
         | remember its documents positions and sizes. That function comes
         | for free with a Document-Based App.
         | 
         | If you want the Document to control the properies of the
         | desktop, then I would write a little Automator app, shell
         | script, Shortcut, etc. to do that and then add that to the
         | Stapler Document. Use all available tools together.
         | 
         | ---
         | 
         | Internet Archive: yes, that was me. Most of my account data is
         | still gone. I don't think the deleted data will ever be
         | restored. And so it goes. The blog post about that one has been
         | updated with this info. Thanks for asking.
        
       | crooked-v wrote:
       | Any chance this could add launching windows to specific
       | positions/sizes and/or, more importantly, to specific spaces?
       | 
       | It still feels nuts to me that we have all this stuff and yet
       | when entering/exiting 'work mode' I have to either leave
       | everything running indefinitely or reposition all my work apps
       | every time I launch them.
        
         | samstave wrote:
         | We might be looking for this:
         | 
         | https://github.com/FancyWM/fancywm
        
         | msephton wrote:
         | I would recommend using another tool to script those sorts of
         | changes to the workspace, and then adding that to the Stapler
         | Document.
         | 
         | There is an app called Stay that remembers positions of Windows
         | based on the app, title, etc. I used it for a while, but not
         | recently. https://cordlessdog.com/stay/
        
         | replete wrote:
         | You're not alone with this desire, and I still haven't found a
         | good solution. I want to bookmark all apps and windows when
         | working on something and recall them all later when I resume
         | work. How is this not yet a thing when do much real work
         | involves using so many different applications?.
         | 
         | There is an app, Workspaces, I think, but it's not useful
         | enough to bother using.
         | 
         | Probably should be a macos feature one day
        
           | prmoustache wrote:
           | KDE Activities
        
             | msephton wrote:
             | There's probably something more comprehensive and recent,
             | but I couldn't find it:
             | 
             | What is an activity in KDE and what can I do with it?
             | https://askubuntu.com/a/705835
        
         | BurningFrog wrote:
         | I use Keyboard Maestro to do this for my needs.
         | 
         | May not work for every case.
        
           | msephton wrote:
           | Can you say a bit more about how you've set this up in
           | Keyboard Maestro? Thanks
        
             | BurningFrog wrote:
             | Sure!
             | 
             | I have a bunch on windows in an app, that tend to move to a
             | different monitor after the machine goes to sleep.
             | 
             | Each window has a different title, which is something KM
             | can act on, so I've made an action that moves each
             | individual window to a specific place. I've tied this
             | action to Alt-P (for "place"), so I can manually correct
             | when they've drifted.
             | 
             | So it's not a generic "put all windows where I left them"
             | solution, but it's a hell of a lot better than manually
             | doing the same thing several times a day.
        
               | msephton wrote:
               | Nice! I do something similar with my laptop using
               | Hammerspoon: when it detects my external keyboard is
               | connected over USB it does some setup for my desk/mobile
               | environment (repositions dock, quits some apps, launches
               | some apps, etc). I manage my windows in quarters and
               | thirds using keyboard, so they don't really move about.
        
         | eddyg wrote:
         | Moom(1) offers the ability to save and restore window layouts,
         | including triggering saved layouts on addition or removal of
         | displays.
         | 
         | (1)https://manytricks.com/moom/
        
           | toomuchtodo wrote:
           | $10 is incredibly reasonable for this product, thank you for
           | sharing.
        
             | eddyg wrote:
             | You're welcome.
             | 
             | I've been a Moom user for a long time, and the _craziest_
             | thing to me is when they had to change(2) from using a
             | miniature rectangular grid for positioning and resizing a
             | window to a slanted hexagonal grid _because of a patent_
             | (3).
             | 
             | (2)https://manytricks.com/blog/?p=4618
             | 
             | (3)https://patents.google.com/patent/US20090300541A1/en
        
           | msephton wrote:
           | I wonder if they experimented with adding app/document
           | launches into the mix? Seems like the missing piece.
        
         | chongli wrote:
         | I leave everything running. I have a dozen spaces filled with
         | assortments of windows for different tasks. It's a real pain
         | because some apps (such as the browser) have windows open on
         | all of the spaces and macOS really doesn't like it when you
         | have the same application in multiple different spaces.
         | Clicking a link in an email is such a roll of the dice (as to
         | which space I'll end up in and which browser window will
         | receive the new tab) that I don't bother clicking and test copy
         | paste the link where I want it to open.
         | 
         | It's especially bad when I need to restart the browser because
         | then all the windows get collected into one space again. Also
         | annoying that relaunching the browser reopens all those windows
         | in the first place.
         | 
         | I like the idea of this app for launching a collection of apps
         | together but the application is the wrong level of granularity.
         | I don't want all of my browser windows at once. I want just one
         | of them along with the windows of other applications that match
         | that task.
         | 
         | I bet there's some combination of tools I could cobble together
         | and customize to achieve this but I don't want to work that
         | hard at it. I really should be able to just open up a new
         | space, open up and arrange all the windows I want to work with
         | on tasks for that space, and then press save and give it a
         | name.
         | 
         | Then I should be able to close that space and reopen it by name
         | any time I like, with all of the windows exactly as I left
         | them, regardless of whether or not any of those applications
         | are open on other spaces.
        
           | the_other wrote:
           | Agreed. It's weird because the basic app+window UX in macOS
           | (in which an app can be running with no windows open) implies
           | the task based behavior that Stapler is trying to support.
        
             | msephton wrote:
             | I'm not sure the current app/window paradigm does suggest
             | that, see my sibling reply.
        
               | the_other wrote:
               | Fair. It sounds like earlier tech went further than the
               | macOS UX.
               | 
               | It's a shame we don't have better task support. macOS has
               | been slowly shidting further towards app-centric
               | workfkows. I suppose this is in line with app stores, web
               | apps and mobile OSs being the more common computer
               | interfaces now. It's disappointing, in my opinion.
        
               | msephton wrote:
               | We've left so many great and useful things behind in the
               | name of "progress". I encourage you to try old systems,
               | even just for as long as it takes to type a document,
               | edit an image, or manage some windows, organise some
               | files, to see how they all did things and what each
               | brought to the desktop.
               | 
               | Here's a playlist of demos of great but obsolete
               | operating systems:
               | https://www.youtube.com/playlist?list=PLfF-
               | zlMNYMd_ZioGb0BKd...
        
           | msephton wrote:
           | I think this is the dream, but we're paddling upstream here
           | as the OS itself is app-centric and apps are mostly document-
           | centric.
           | 
           | Xerox Star & Smalltalk had the task-centric approach and Alan
           | Kay @alankay has said that Steve Jobs/Apple missed that
           | aspect in their takeaway from their visit: "(they) missed a
           | few things about the GUI. For example, that it had unlimited
           | and persistent "desktops" which could be used to sustain
           | work/projects over time without having to tear down and build
           | up, and without stovepiped apps, etc."
           | 
           | https://www.quora.com/What-was-it-like-to-be-at-Xerox-
           | PARC-w...
           | 
           | So happy that I could remember enough of this story to find
           | that link.
        
             | kevin_thibedeau wrote:
             | The Lisa was doc-centric so Apple definitely didn't miss
             | that aspect. They abandoned it because harddrives were
             | expensive and needed a cheaper base system running single
             | apps off floppy.
        
               | msephton wrote:
               | I think they called them "contexts" on Lisa, but as you
               | say it was referred to as document-centric.
               | https://www.youtube.com/watch?v=n1CvRKdV0Ls
               | 
               | But Alan Kay was talking about task-centric, not
               | document-centric, which I'd argue Lisa wasn't _quite_
               | doing fully.
               | 
               | Happy to talk about this more if you think I'm mistaken.
               | And you'll need to let Alan Kay know :)
        
             | dredmorbius wrote:
             | Crossing the streams (see:
             | <https://news.ycombinator.com/item?id=41217330>, and I know
             | msephton has), _task-centric_ UI seems to me to have
             | traditionally been accomplished on Unix-like platforms
             | through directories (often task /project-related), and
             | Makefiles, which can combine a set of related operations
             | across a large number of tools in a single context.
             | 
             | Neither of these are, of course, user-friendly for the vast
             | majority of people. But they _do_ afford some thoughts,
             | concepts, and mechanisms which might be used in task-
             | oriented UI design.
        
           | JadeNB wrote:
           | > Also annoying that relaunching the browser reopens all
           | those windows in the first place.
           | 
           | This is the browser's decision, not macOS's, though. At least
           | for Firefox, you can turn it off ("Open previous windows and
           | tabs" in General > Startup).
        
             | chongli wrote:
             | I don't want to lose all those windows and tabs though.
             | 
             | I guess what I really want isn't possible without either
             | ugly hacks or a total rearchitect of the operating system:
             | the elimination of the "stovepipe" applications paradigm.
             | 
             | Applications should not own their windows, the operating
             | system should. In practice this would mean an application
             | is not a program you invoke by clicking on it. Instead it
             | should be a library you install that tells the operating
             | system how to read, display, edit, and write certain kinds
             | of documents or document-like resources (such as web
             | pages).
             | 
             | Then it would be easy for the operating system to offer
             | unlimited persistent desktops that need to only remember
             | which resources are open and a bit of metadata controlling
             | the appearance of each window (position, shape, size, view
             | setting).
        
               | JadeNB wrote:
               | I dunno--I see the appeal of what you say, but, on the
               | other hand, the closer the OS comes to locking in
               | different things that an app might want to do, the more
               | we risk the iOS set-up where you can use any browser you
               | want, as long as it's WebKit. That is, one unified
               | paradigm is great, as long as you like that paradigm!
               | 
               | I guess one can image a "skinnable" OS, where the OS
               | enforces, say, one approach to window management on all
               | apps, but there are options for what the One True Window
               | Management strategy is. I'm sure I'm describing something
               | in Linux, but I'm a Mac user and so not used to such
               | freedom.
        
         | latexr wrote:
         | > more importantly, to specific spaces?
         | 
         | Apple does not provide APIs for that. A handful of apps control
         | spaces, and all of them by automating GUI actions.
        
         | mrbombastic wrote:
         | I also have wanted this for a long time, is there a limitation
         | on macOS that prevents this? It doesn't sound that hard but
         | maybe if apis aren't there it is.
        
           | msephton wrote:
           | First, make sure that: System Preferences > General > Desktop
           | & Dock > Windows > Close windows when quitting an application
           | = OFF
           | 
           | Then leave the windows of an app open as you quit it. When
           | you next launch the app its windows will restore to their
           | previous size and position. If you close the windows first,
           | then the app will restore to having no windows open.
        
             | JadeNB wrote:
             | In Sonoma, the same preference is there, but it's one level
             | less nested: System Settings > Desktop & Dock etc.
        
       | mistrial9 wrote:
       | Tic-tac-toe desk accessory with the minimal DA support in system
       | 10.4 .. running right now.. that binary is close to 40 years old
       | if I am not mistaken.
        
         | msephton wrote:
         | Can you please share more details about this? Links? Thanks
         | 
         | Edit: ah, I think you're referring to Mac OS X Classic
         | Environment running old system in which you're running the old
         | Desk Accessory. Matryoshka dolls!
        
           | mistrial9 wrote:
           | no it is not "classic" nor Matryoshka .. there is a bit of
           | wrapper code that was introduced in the OS 9 transition, and
           | that code still executes under OSX..
        
             | msephton wrote:
             | Then, please, I need to know more about this! :) a link, a
             | screenshot, whatever you can provide.
        
       | webwielder2 wrote:
       | My mind went to http://macintoshgarden.org/apps/simstapler
        
         | msephton wrote:
         | You're not the only one! My friend Japhy Riddle said the same.
         | Classic Mac Users, eh? :)
        
       | iambateman wrote:
       | This is really cool -- I've wondered why something like this
       | didn't exist for a long time and I'm looking forward to checking
       | it out.
       | 
       | Thanks for filling in the gaps for all of us who don't just use
       | one app at a time!
        
         | msephton wrote:
         | Power users of the world, unite!
        
       | willcodeforfoo wrote:
       | Nice! Similar to Brett Terpstra's Bunch[1] which has a GUI-less
       | approach.
       | 
       | [1]: https://bunchapp.co/
        
         | msephton wrote:
         | Thanks for sharing! This is new to me.
         | 
         | The documents saved by Stapler are also plain text (JSON). But
         | because the app is trying to be a model citizen in the current
         | model of macOS security/annoyance, it contains the file
         | bookmarks that macOS gives us (which are binary blobs encoded
         | as Base64 text, so incomprehensible to mere humans) rather than
         | the human-readable file paths you might expect. Kind of
         | annoying, but there we go!
        
       | pcblues wrote:
       | I was disappointed it wasn't MacPlaymate he remade ;p It had a
       | boss key that would show a spreadsheet image.
        
         | msephton wrote:
         | One of my oldest games, Wire Hang Redux, had a boss key that
         | would make it look like Notepad/TextEdit.
         | https://www.mobygames.com/game/109304/wire-hang-redux/screen...
        
       | sublinear wrote:
       | If anyone uses KDE Plasma, you probably already know how broken
       | activities are.
       | 
       | Can we make it more like Stapler?
        
       | rcarmo wrote:
       | I like this. Curious as to how it plays along with the mess that
       | is Stage Manager...
        
         | msephton wrote:
         | Do let me know! For my sins, I've never used Stage Manager.
        
           | rcarmo wrote:
           | Well, right now the app itself doesn't work for me. I create
           | a new document, drag a couple of images onto it, save the
           | document, and it goes blank.
           | 
           | I tried adding a folder and Visual Studio Code as the things
           | to open (because Visual Studio Code can open, well, anything,
           | and this way I could at least start up a workspace) and got
           | the same result.
        
             | msephton wrote:
             | I can't reproduce this, but it's been filed as bug on
             | GitHub so I'll look into it.
             | https://github.com/gingerbeardman/stapler/issues/3
        
             | msephton wrote:
             | This issue has been resolved in version 1.1
        
       | keyle wrote:
       | How attractive was the old UI? I really wish my mac could look
       | just like that today. Okay okay, maybe with dark mode at night!
        
         | msephton wrote:
         | It really was, still is. It's been downhill since, in many
         | ways.
        
       | outadoc wrote:
       | Couldn't you do all of that with fairly simple, native Shortcuts?
       | Or even Automator scripts?
        
         | webwielder2 wrote:
         | One could do anything far less conveniently.
        
         | create-account wrote:
         | An Alfred workflow
        
           | msephton wrote:
           | Indeed that would work but it is definitely more difficult to
           | set up and maintain. New workflow (enter data), new action
           | (enter files). And so on. But I do love Alfred!
        
       | mwcampbell wrote:
       | I wonder what the executable size of the original app was. Of
       | course, 471 KB for a modern app, including both x86-64 and ARM64
       | builds, is pretty good.
        
         | msephton wrote:
         | Stapler 1.1 (1993) is 223KB (68K-only)
         | 
         | LaunchList 0.8 (2009) is 880KB (Intel-only)
         | 
         | ...but interestingly LaunchList contained an unused "test" icon
         | file weighing 320KB(!) so really it is 560KB.
        
       | vcool07 wrote:
       | I'm always curious to know whats the motivation behind these kind
       | of side projects ? Is it just to scratch a technical itch ? To
       | build a product for oneself because you are not really happy with
       | anything else on the market ? Learn a new skillset ? Enhance the
       | resume with a new cool project ?
        
         | tgsovlerkhgsel wrote:
         | At least for me, side projects are just another hobby. Some do
         | woodworking, some garden, and very rarely is a hobby _actually_
         | about the product.
         | 
         | Most IT people around me, like myself, enjoy building things. A
         | side project is a good opportunity to do so "just because",
         | without bullshit you don't like - no bureaucracy or approval,
         | no story points, no project meetings, no design documents,
         | writing tests and documentation is up to you. You just sit
         | down, do, and get the feeling of actually making progress in a
         | reasonable time and at the end of the day, having built
         | something. It's energizing.
         | 
         | Sometimes, it _is_ about the product though, and you build
         | yourself a nice tool because you aren 't happy with what's out
         | there. Of course, the two goals can often be combined - and at
         | the very least, some useful product is a good _excuse_ to
         | practice the enjoyable hobby.
        
         | msephton wrote:
         | For me it was to scratch the itch of creation. I live for the
         | buzz of creation. There was also a degree of wanting to see how
         | it was to create an app using the latest tools that I don't
         | normally use, I link to a tweet where I suddenly decide to try
         | and make this app, a flash of inspiration that it should be
         | possible. If it had been more difficult, I would have surely
         | given up and the app would not exist. But it was "easy" enough,
         | and here we are. Plus, the original app has been stuck in my
         | brain for a long time and I remembered it fondly. So, there are
         | many factors... but adding things to my resume is not one of
         | them.
        
       | dredmorbius wrote:
       | _It's an odd way of thinking about working on a computer--it's
       | task-based rather than app-based or document-based._
       | 
       | If I've one frustration with computer interfaces, dating back to
       | the 1990s, it's this. If anything it's become _worse_ with time
       | as apps, both desktop and mobile though especially the latter,
       | become more self-centric, to the point of having their own, non-
       | filesystem-based, data silos. I understand some of the security
       | reasons for this (apps are themselves increasingly untrusted and
       | untrustworthy, and data-sharing is a significant risk). But it is
       | extraordinarily frustrating when trying to work with multiple
       | tools.
       | 
       | Modern MacOS is particularly pernicious in that I'm often working
       | between multiple _applications_ , but on the same _project_ , and
       | the friction of raising and lowering all _app_ -associated
       | windows as I cycle between these, often navigating to a workspace
       | I'd not meant to go to, is quietly maddening.
       | 
       | The Linux / X-Windows notion of focus-follows-mouse addresses
       | this _somewhat_. Your _current_ app is whatever the mouse happens
       | to be on top of. On MacOS this simply isn 't available, though
       | there are some ... hints of this. E.g., if I happen to have the
       | mouse over a browser window I can scroll that window with the
       | mouse. But if I then, say, hit Cmd-W to close that tab ...
       | suddenly the _actually_ focused app which I 'd forgetten about
       | gets a kick in its nethers. This happens to me several times a
       | week, if not per day.
       | 
       | I don't know that Stapler is the true solution to this, but it
       | does seem to track in that direction.
        
         | msephton wrote:
         | Check out my comment about Xerox Star & Smalltalk and what
         | Apple missed from their visit to PARC:
         | https://news.ycombinator.com/item?id=41215350
        
           | dredmorbius wrote:
           | I saw that, appreciate it, and agree ;-)
        
         | bane wrote:
         | The history of Operating System development is really
         | interesting in that the decisions of what the atomic element of
         | the system are (files, documents, or applications) lock all
         | future development into a certain path, but all the choices not
         | made then have to be somewhat retrofit into the design. For
         | decades systems have dwelled in a kind of morass where they
         | seem to focus on trying to implement different variants of the
         | other two, with one of these atomic elements as the core
         | concept.
         | 
         | For example, the dominant atomic concept in Xerox Star was the
         | document [1]. Documents are an abstraction just above files. A
         | webpage is a document, but is made up of numerous files like
         | the graphics, fonts, executable scripts, etc. Document oriented
         | systems like Star also deemphasize applications. The system is
         | supposed to open up the correct application(s) when you choose
         | to interact with a document. But even with this as the core
         | abstraction, the system still had to provide methods to work
         | directly with files and applications.
         | 
         | Other systems, like Plan 9, _nixes, MS-DOS, CP /M, etc. focus
         | on the file as the atomic primitive and try to build around
         | that. But when things moved to GUIs, many of the development
         | teams focused on the Applications. Windows 3.x famously only
         | showed users organized collections of applications, with file
         | management as just another application. But Windows 3.x was
         | sitting on top of DOS which oriented itself around files. The
         | _nixes in the meanwhile forgot about documents almost entirely.
         | 
         | Where I think they've failed to evolve is not in reimplementing
         | these three things over and over, but in assembling them into
         | useful, higher-level, abstractions. What I really think is
         | missing is a way to assemble two higher-levels: workplaces
         | which implement workflows.
         | 
         | Pipes and scripts sort of mimic workflows, and desktops sort of
         | mimic workplaces, but these concepts have really stalled and
         | there's almost no real system-level tooling for building these
         | things, especially in a GUI. For example, scripts are really
         | used as a kind of a way to assemble pipes into pseudo
         | applications + automation, but it's hard to turn them into real
         | workflow tools, and desktops just allow you to dump a bunch of
         | application windows and files into one place, but there isn't
         | any real scoping to it.
         | 
         | 1 - https://youtu.be/xJzYRgmnJrE
        
       | idle_zealot wrote:
       | So, is this basically a tray editor for .sh files that just
       | contain a list of applications/shortcuts to run?
        
         | msephton wrote:
         | No :) but that's a close approximation.
         | 
         | The editor is a native macOS window that's kind of like list
         | view in a file manager, or a spreadsheet, or a little
         | folder...depending on your point of view. Plus some menu
         | commands and keyboard equivalents.
         | 
         | The items in each list are macOS "bookmarks" which are a type
         | of authorised/verified/secure alias (in fact, they're still
         | called aliases in the code) that have been around for about
         | 10-15 years. They contain the path plus a bunch more info. As
         | macOS becomes more locked-down the recommended way of accessing
         | files is to retrieve these bookmarks through the normal layers
         | of system permissions and security. Without the bookmarks, for
         | example just using plain text paths, I would not be able to
         | show the full images in Quick Look or easily launch the list
         | items. A key benefit is that the bookmark will still resolve if
         | the file is moved somewhere else on the same disk, or even to a
         | different volume!
         | 
         | Here's more info on file bookmarks:
         | https://eclecticlight.co/2020/05/21/bookmarks-a-type-of-alia...
         | 
         | I store the items as JSON in the saved file, simply because I
         | prefer it to XML (which is the main/default option). I wanted
         | the files to still be human readable and editable to a degree.
         | 
         | The files are launched using the default app specified by that
         | file, so it can be changed on a per-file basis. Individual
         | images might open in an image editor, image viewer, app to run
         | OCR, script to run OCR on it, etc.
        
       ___________________________________________________________________
       (page generated 2024-08-11 23:01 UTC)