I've been writing Autumn on and off for a few months, because there's something really satisfying and rewarding about automating something you do often, and then using that to automate more, and building upward in a cycle.
That, plus I wanted to see how close to building a "legit IDE" I could get while completely faking it with WKWebViews. So Autumn kind of grew from those two principles and I'm really happy with how it turned out.
I'd be glad to answer any questions, I'll be here for a few more hours. (I don't have internet at home so I use the library's wifi for stuff like this, and it closes early today.)
Regarding ESM (ECMAScript modules), I did implement require() and module.exports to the best of my ability, so it should be pretty easy to modularize your scripts. But it doesn't have a Node.js runtime so I didn't focus too much on node_modules support, although in theory many packages should work fine.
Regarding online documentation, good idea, thanks! I'll try to add that this week. Although, the app is so much more than its API, which is what makes it so unique, and I think if people just look at the API itself, they don't quite get to feel the experience of using Autumn to create their own automation workflows, which is what I'm most proud of about Autumn.
Also, sorry for the terrible website. Web design is not my forte, I'm an app guy, and this was the quickest thing I could hack together in a couple days. Also I'm aware of the issues with the video demo, I'm uploading the file to YouTube so it should be fixed soon!
Nothing terrible about the website, in my opinion. It gets the job done without getting in your way. And you can always improve based on experience and feedback.
Things I noticed right a way:
- The logo and the title font. There's nothing wrong about them, but they don't reflect much about the application
- Scrolling, there are a few elements that appear over the header bar
This site is great. It's clean, easy to read, and looks professional.
It's hard for me to evaluate how useful this would be to my workflow without seeing the API, and it looks like I have to actually run the app to do that. It might be worth putting a copy on the website.
Whoa I got that too! I usually use Safari or Firefox (Google creeps me out) but I have tested the whole site in all three browsers, except this one button in Chrome I guess :D I'll check it out, thank you!
> Uncommonly downloaded is applied to any download that is new or has been modified/updated until Google has a chance to examine the download using multiple data centers. Once the download has been examined enough times, the warning will be removed.
So apparently we just have to wait until Google's servers decide my app isn't dangerous. Ironic considering I paid the $100 for Apple to notarize the app through Developer ID to remove that same warning from macOS when you first launch the app!
That is a great list! Autumn's API was inspired by a lot of these, so you may find some similarities, although I redesigned Autumn's API from the ground-up to be intuitive, simple and predictable, and so that it would lend a lot more easily to the built-in documentation viewer. Searching through online documentation was always one of my most sore points when using other programmable window managers, so that was one of my biggest focuses in Autumn, and one of the aspects of it I'm most happy with how it turned out. That, the developer console, and the integrated IDE (Monaco editor), are some ways that I felt I could take the next step up from earlier window managers.
> Searching through online documentation was always one of my most sore points when using other programmable window managers
For me that is always one of the most sore points of almost every single desktop application, or at least those released this side of the millennium (older stuff tend to have actual offline documentation with them).
I don't use macOS these days (i dislike how Apple doesn't care about backwards compatibility and every time i upgrade macOS i have apps i bought break left and right - at this point almost nothing works on my oldest iMac), but thumbs up for providing your users documentation with the software they bought instead of sticking it to some wiki in a web server somewhere and hoping for the best (of course having the docs available on the web is fine and for some welcome, since they can check out what the app can do before even buying it, just not as a replacement for local docs you can pull up at any moment regardless of your internet connectivity - or even version of the software).
It would also be great to flesh out the accessibility and speech recognition APIs, and make it possible to write all kinds of intelligent application automation and integration scripts, bots, with nice HTML user interfaces in JavaScript. Take a look at what Dragon Naturally Speaking has done with Python:
I would like to discuss how we could integrate Prefab with a Javascriptable, extensible API like aQuery, so you could write "selectors" that used prefab's pattern recognition techniques, bind those to JavaScript event handlers, and write high level widgets on top of that in JavaScript, and implement the graphical overlays and gui enhancements in HTML/Canvas/etc like I've done with Slate and the WebView overlay.
Video: Prefab: What if We Could Modify Any Interface? Target aware pointing techniques, bubble cursor, sticky icons, adding advanced behaviors to existing interfaces, independent of the tools used to implement those interfaces, platform agnostic enhancements, same Prefab code works on Windows and Mac, and across remote desktops, widget state awareness, widget transition tracking, side views, parameter preview spectrums for multi-parameter space exploration, prefab implements parameter spectrum preview interfaces for both unmodified Gimp and Photoshop: http://www.youtube.com/watch?v=lju6IIteg9Q
PDF: A General-Purpose Target-Aware Pointing Enhancement Using Pixel-Level Analysis of Graphical Interfaces. Morgan Dixon, James Fogarty, and Jacob O. Wobbrock. (2012). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '12. ACM, New York, NY, 3167-3176. 23%. https://web.archive.org/web/20150714010941/http://homes.cs.w...
Video: Content and Hierarchy in Prefab: What if anybody could modify any interface? Reverse engineering guis from their pixels, addresses hierarchy and content, identifying hierarchical tree structure, recognizing text, stencil based tutorials, adaptive gui visualization, ephemeral adaptation technique for arbitrary desktop interfaces, dynamic interface language translation, UI customization, re-rendering widgets, Skype favorite widgets tab: http://www.youtube.com/watch?v=w4S5ZtnaUKE
PDF: Content and Hierarchy in Pixel-Based Methods for Reverse-Engineering Interface Structure. Morgan Dixon, Daniel Leventhal, and James Fogarty. (2011). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '11. ACM, New York, NY, 969-978. 26%. https://web.archive.org/web/20150714010931/http://homes.cs.w...
Video: Sliding Widgets, States, and Styles in Prefab. Adapting desktop interfaces for touch screen use, with sliding widgets, slow fine tuned pointing with magnification, simulating rollover to reveal tooltips: https://www.youtube.com/watch?v=8LMSYI4i7wk
PDF: Prefab: Implementing Advanced Behaviors Using Pixel-Based Reverse Engineering of Interface Structure. Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 1525-1534. 22%
https://web.archive.org/web/20150714010936/http://homes.cs.w...
PDF: Prefab: What if Every GUI Were Open-Source? Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 851-854. https://web.archive.org/web/20141024012013/http://homes.cs.w...
Today, most interfaces are designed by teams of people who are collocated and highly skilled. Moreover, any changes to an interface are implemented by the original developers and designers who own the source code. In contrast, I envision a future where distributed online communities rapidly construct and improve interfaces. Similar to the Wikipedia editing process, I hope to explore new interface design tools that fully democratize the design of interfaces. Wikipedia provides static content, and so people can collectively author articles using a very basic Wiki editor. However, community-driven interface tools will require a combination of sophisticated programming-by-demonstration techniques, crowdsourcing and social systems, interaction design, software engineering strategies, and interactive machine learning.
I feel deeply aligned with the goals of this project, but unfortunately (for me) I think a given solution is not really hackable unless it's open source.
Depending on a given indivudual's opinions, availability, etc tends to be at odds with hackability.
At the same time I respect the author's desire to be rewarded for his work. Perhaps Patreon or the like could be a sustainable model. It's what the iTerm author uses (and quite a few other people who I do support).
Patreon's model relies on monthly fees, which is something that philosophically I am against with software like Autumn, because it's not a continual service but a product that took a finite time to complete, so it should have a finite price. I also took counsel of someone who makes over $10k / month in monthly donations for open source work, who strongly recommends against it for personal products but encourages it for products that can benefit organizations.
Patreon has a per-accomplishment tier, used by (e.g.) the "Pepper and Carrot" webcomic[1] to fund each page individually. You might consider that model for features...
It's a neat API as far as window managers go.
But I'm afraid I can't use it unless it is open source.
Most WMs are open source, Xmonad, awesome, and i3 come to mind. With a little bit of hacking, you can setup Xmonad w/ XQuartz on OS X, but it is a bit buggy. I couldn't get xmobar to work, and keybinds don't work all the time, especially if XQuartz has an existing keybind for that particular key.
That's why it's paid: I've tediously worked out all the kinks over months and months of work. Obviously no software can be guaranteed to be bug-free, but I'm the #1 user of Autumn and I have gotten rid of every single bug I could find and polished every single corner-case and sped up every operation. I generally avoid making bold claims, but I'm confident this is the smoothest, fastest, and most fun window manager for macOS as of 2019.
Generally speaking with those sorts of small indie programs you are paying for quality and convenience. Having to do "a little bit of hacking" and - especially - running an X server on macOS as your primary window system so that you can have some customizability doesn't exactly bring quality to my mind, but it might be me :-P
(of course for some the ability to be able to edit the source code of their window manager might be something they absolutely need, but they may just not be the target audience and... well, even then, you don't need the license to be open source, just the source code available and perhaps a license that allows sharing patches among people who already have the code)
> Generally speaking with those sorts of small indie programs you are paying for quality and convenience.
If I care about convenience, why wouldn't I just use the default WM?
Quality is also debatable. For a WM productivity is far more important than quality.
> If I care about convenience, why wouldn't I just use the default WM?
Because it might not have the functionality you want. Things aren't black and white, but one solution might be closer to what you need than jury rigging something yourself.
> Quality is also debatable. For a WM productivity is far more important than quality.
We'd need to agree both on "quality" and "productivity" here since those do not have well defined meaning. For me when it comes to software that helps me be productive, quality includes it helps me be productive, so there isn't a relationship where i can say that one is more important than the other since one implies the other.
Forum for discussion is actually one of my highest priorities for this month! I'm not settled on whether to use something like Discourse, phpBB, a subreddit, a mailing list, a custom forum, or a GitHub repo with Issues enabled. This requires more thought, and maybe more discussion, but it was on the todo list since day one of writing Autumn.
I will look into reacting to Mac notifications, that sounds like it could be useful but I'm not sure I understand what it means. Could you elaborate?
If the subject is interesting/useful I don’t believe forum software matters that much to us users. All those that you mentioned would work fine, I’d say.
Notification issues I have tried to solve with Bettertouchtool and Hammerspoon, but I havent been able to find notification API access in them. Though I don’t know if Apple provides such access to notifications. Use cases I have are reacting to Slack, iTerm, Mail and browser notifications as events. I’d like to access the notification content in plain text or object and then decide how to process it. Depending on message content, time of day, place, connected network &c I could put up rules on how to proceed. I could show notifications on touchbar or on screen in less distracting ways than what notification center allows. I could pool certain notifications and check them all in one place, such as bot messages from various slack channels.
Notifications seem easier way to get information moving between apps than trying to use their specific APIs (if such is even available). Sort of light weight RPC from apps to my custom tools.
That does sound very useful, yeah. I'll look into whether it can be done, but my gut feeling is that it can't. Typically apps can only respond to their own generated Apple notifications, not those generated from other apps.
Yes, Hammerspoon goes in many different directions with its API, providing not only the kitchen sink but the house and the neighbors' houses, but lacking the paintings and many walls. That inspired a lot of decisions in how I designed Autumn's API, because I wanted the user experience to be buttery smooth from start to finish, and I wanted the API to be both useful and comprehensive without being overwhelming or spartan.
Slate is great, it was one of the first window managers I ever tried. In fact Slate inspired a good portion of the early versions of Autumn. You can almost think of Autumn as Slate with an embedded IDE, built-in documentation, developer console, and an API designed with TypeScript in mind.
I was also quite inspired by Slate. Unfortunately there hasn't been any activity with it for about 5 years or so. It's great you're picking up the mantel and running with it, because the essential idea is great!
I was interested in Slate because I was looking for a good way to implement pie menus for a Mac window manager. And I'd already implemented pie menus for HTML, so I wanted to come up with a way to use that code (and any other html user interface or graphics too, of course) in the window manager.
About 5 years ago I opened this issue, describing an experiment I did making the web browser in a topmost window with a transparent background to implement user interface overlays scripted in HTML.
Slate used a hidden WebView for its scripting engine. So I made it un-hidden and float on top of all the other windows, and was easily able to use it to draw any kind of user interface stuff on top of all the other Mac windows. And I could track the position of windows and draw a little clickable tab next to or on top of the window title bar, that you could click on to pop up a pie menu.
It actually worked! But I didn't take it much further, because I never got any feedback on the issue I opened, so gave up on using Slate itself, and never got around to starting my own JavaScript window manager myself (like you did!). I opened my issue in June 2013, but the last commit was Feb 2013, so development must have stopped by then.
But I wrote up a description of my ideas about "aQuery" (like jQuery, for accessibility), and bounced the idea off of some people who are into accessibility and user interface design, and learned about Morgan Dixon's work on Prefab, something you should definitely check out if you're developing a window manager.
Here's an HN posting that describes Morgan Dixon's "Prefab" -- imagine how powerful a window manager would be if it could do all that stuff, fully programmable from JavaScript, in combination with full access to the Accessibility APIs.
Morgan Dixon's work is truly breathtaking and eye opening, and I would love for that to be a core part of a scriptable hybrid Screen Scraping / Accessibility API approach.
Screen scraping techniques are very powerful, but have limitations. Accessibility APIs are very powerful, but have different limitations. But using both approaches together, screencasting and re-composing visual elements, and tightly integrating it with JavaScript, enables a much wider and interesting range of possibilities.
Think of it like augmented reality for virtualizing desktop user interfaces. The beauty of Morgan's Prefab is how it works across different platforms and web browsers, over virtual desktops, and how it can control, sample, measure, modify, augment and recompose guis of existing unmodified applications, even dynamic language translation, so they're much more accessible and easier to use!
This sounds incredibly useful and is something I am going to strongly look into and consider as a future (separate) project. Thanks for sharing these thoughts!
I've been writing Autumn on and off for a few months, because there's something really satisfying and rewarding about automating something you do often, and then using that to automate more, and building upward in a cycle.
That, plus I wanted to see how close to building a "legit IDE" I could get while completely faking it with WKWebViews. So Autumn kind of grew from those two principles and I'm really happy with how it turned out.
I'd be glad to answer any questions, I'll be here for a few more hours. (I don't have internet at home so I use the library's wifi for stuff like this, and it closes early today.)