Scripting the Haiku GUI with hey
haiku-os.org
haiku-os.org
Over time I've built up a small list of utilities for common UI interactions. Here's an example: Get the list of tabs from the frontmost Safari window [0]. Occasionally I'll be researching some topic with a bunch of tabs open, and I want to go work on something else. When that happens I just grab all the URLs in that window and save it in a text file which I re-open later when I want to continue researching the subject.
IMO, the biggest problem I've encountered with OSA scripts (and presumably it also applies to this hey tool) the lack of REPL and inspector. On macOS you can use Safari's dev tools to debug JS OSA scripts, but it's incredibly brittle. Trying to access certain object properties will just cause it to crash, or it might print the identifier of the thing which you're accessing which doesn't add much value.
[0] https://gist.github.com/cesarandreu/8d6ccd70bcac81d1a45941ae...
And of course there is the Hey source itself, which you could use as a reference to write a new scripting platform with (https://github.com/haiku/haiku/blob/master/src/bin/hey.cpp).
Honestly, I just find it convenient to get a list of URLs, and dealing with regular text files. Sometimes interfaces are too limiting r slow, and manipulating the list in a text editor ends up being easier.
Another of my use-cases for this is to regroup tabs when I fork into random topics. e.g. Sometimes I end up opening a bunch of tabs that are tangentially related to the subject and I want to move em into a new window or stash em for later.
It's also convenient to grab a manually opened list of URLs in cases where I want to perform some one-off scraping task.
Its gotten to the point that I can't seem to really function on a new MacOS installation without my personal Hammerspoon repo set up .. I'm not sure if thats a positive or a negative result of having such deeply scriptable interfaces, but perhaps it can be looked at both ways.
Somehow "hey" just doesn't seem to offer the ecosystem that AppleScript does. Even though I really don't like the latest versions of macOS and iOS, I still prefer the old Apple ecosystem to the fragmented platforms of Windows and Linux (or Haiku).
File reading and writing are easy. Getting and setting track data in iTunes is easy. Finding selected items in the Finder is easy. I've been using more "do shell script" recently as my knowledge of command-line tools increases.
It's slower to run than other languages, but when I just want a quick one-off script to generate some data, it's faster for me to code it in AppleScript instead of spending hours debugging it in another language.
All my processing for PlinyPedia ( http://peterburk.github.com/pliny ) was in AppleScript - splitting the XML into separate files grouped into folders, naming those folders, moving the footnotes to the bottom and adding links to quickly move up and down, and finally generating a basic iUI interface.
I also wrote scripts to transpose chord progressions to Roman Numerals by looking up the values in a table, select cells diagonally in Excel, and turn my Facebook friends list into an iTunes database. (The iTunes database is URL tracks that trigger a PHP script running locally that opens Safari with the URL - it's basically a bookmarks manager with Smart Playlists. If you can recommend a better database, please do.)
For example, scrolling down to load all my Facebook messages into the left-hand bar. Or segmenting text into 5000-character blocks, copy-pasting into Google Translate, and getting the output.
With any command-line tools, it would be a hassle, if it's possible at all. With AppleScript, it's easy.
sounds like an X-Y problem. Why wouldn't you just use the facebook API ?
It is definitely lacking in the browser department (which seems so crucial to most people) but beyond that, it’s a very dependable and responsive OS with absolutely modest hardware requirements.
(I also have a working BeBox 603e 133 MHz but I use it very rarely because I’m very concerned about the health of the IDE HD.)
A large part of what did in BeOS was a combination of Microsoft's OEM licensing requirements and Be's steadfast belief that the only path to success was pre-installation on a major PC brand. IIRC, if you offered Windows pre-installations at all, you had to pay for every machine that Windows could be installed on whether or not it was actually installed, and you couldn't offer machines capable of dual-booting. Be concentrated their efforts on BeIA, an "internet appliance" version of the OS, which was dead in the water -- according to a lawsuit Be filed against Microsoft, MS pressured their OEMs not to partner with Be on both BeOS and BeIA. (Microsoft settled the suit for around $24M, IIRC.)
Personally, I think BeOS might have been able to survive as a niche OS if Be had kept their focus solely on it, kept the price competitive with boxed Linux distributions (those were a thing back then), and not been dedicated to the "go big or go home" mantra, but I don't have any inside info to prove (or disprove) that.
... Except that I don't think there is anything they could have done that would have made them successful, at that point in time, other than possibly not playing hardball when Apple came calling. Microsoft's stranglehold on the industry was just too great.
My contribution to the ecosystem, if in fact I ever made one, was to write what I thought of as the best USENET newsreader available on the platform.
http://www.platinumball.net/pineapple/news/beos/
I definitely would still be using BeOS today, as my day-to-day OS, if that were remotely possible, in this day and age.
They didn't - the decided that hardware is too hard, and JLG lost the momentum - but if they'd made a BeBox that people actually wanted, they would definitely have survived in my opinion. A Laptop-format BeBox, for example, would have had an opportunity to really dominate the field video world, in those days.
But, its all history now.
Beautiful machine. Wonderful operating system. Pity they were so inept commercially. That said, I was also a NeXT user, and I’m convinced that Apple wouldn’t have returned to the forefront if they had chosen “Plan Be” instead of the Steve Jobs option.
Not quite. While the file system resided on the Windows or Linux partition as a drive image, to run BeOS you rebooted the computer into BeOS natively; the boot loader booted that drive image from the other OS's file system.
In fact, once in the BeOS environment, you could use the BeOS disk manager and installer to create a BeOS native partition on free space on the main drive or a second drive, and install the OS natively to the PC. Effectively, you could run the full OS on its own for free.
That's exactly what I did for the first few months I used BeOS back in 2000; I was so taken with the OS I bought the full version and tracked down a hard copy of the BeOS Bible and Be Advanced Topics, both of which are still on my bookshelf.
> "I don't recall any licensing requirements pinned to the amount of RAM you had."
There were no licensing restrictions that I was aware of, however it wouldn't run on machines with more than 768MB without a patch.
I must say I was hugely disappointed when Apple chose not to pursue “Plan Be” and opted to purchase NeXT instead. The operating system seemed like overkill and not a good match for Apple’s use-case (single-user machines, media-focussed workflows, with an obvious advantage to be drawn from pre-emptive multitasking and almost real-time multimedia processing). NeXTStep struck me as a much more “workstation-type” OS that would have had little resonance on the consumer and professional market.
It turned out I was wrong: Moore’s Law has made the heavyweight NeXTStep an eminently shoulderable burden, and that it is now so “lightweight” in relative standards that its direct descendant (iOS) can comfortably run on (albeit unimaginably powerful) mobile devices.
I wrote elsewhere in this thread that with the benefit of hindsight I don’t think Apple’s resurgence could have happened had they had chosen Plan Be.
BeOS was quite interesting too. Though it lacked multi-user support, and had a small user community. Its BeFS filesytem had an indexing feature that dwarfs all desktop search features even today - and Windows "Cairo" (1996) / WinFS (2006) that tried to accomplish it too, turned out as vamporeware.
Both NeXTSTEP and BeOS were ahead with multimedia support like real time video player and WYSIWYG editor.
Be failed because it existed in the times of Microsoft dominance, Apple didn't buy it, and it had some major technical deficiencies (many of which have been addressed in Haiku).
R5 PE had that partition size because it installed to a 512MB file within your Windows partition, then booted from that file. Personal Edition was meant to give a way to try BeOS without having to have a second drive or do any partitioning. Once booted into it, you could just launch the Installer app and install to any size partition you pleased.
Be was essentially dead decently before R5 was released, so I disagree with the author's conclusion.
What's so wrong with having multiple options that, in every Haiku thread, someone makes a comment like this?
How many users will this system have at its peak, in your opinion?
So what, we should never produce a new operating system ever again?
NeXTSTEP never caught on and was a commercial failure. macOS is based on it.
Netscape Communicator was open-sourced after it fell to Microsoft and later became Firefox.
Not everything that dies deserved to. Successors are not their predecessors. BeOS provided a good base for developers to work towards, so the project wouldn't get bogged down in trying to be "something new".
I don't think there's anything 'wrong' per se with having alternative operating systems - they may not get mainstream approval, but a lot of what is now mainstream started out as fringe/horizon technology. And in that regard, we ought to encourage the fringe to share their discoveries - it does eventually trickle down.
(Disclaimer: you can have my BeBox when you pry it from my cold dead hands..)