Yes, MacLynx is a real, honest to goodness port of Lynx 2.7.1 to the classic Mac OS, compatible all the way back to System 7. What makes it particularly interesting as a port is its partial integration with the Mac OS: the home page is set through Internet Config, it supports the Speech Manager, you can drop URLs on it and you can even click on links directly (cooooool!). I used it myself on my first Mac, a Macintosh IIsi, for which it was very well suited. It was released as a beta by its original author and no further releases were made, so a couple years back I decided to dust it off, reconstruct the toolchain and do some upgrades to it just for fun. It's probably the most practical browser you can run on a compact Mac, does very well on later 68Ks and runs just fine under A/UX. I build it with CodeWarrior Pro 2, CWGUSI 1.8.0 (comes with CW Pro 2) and Internet Config Programmer's Kit 1.4.
The original idea for this new beta 4 was to do both some updates to the Lynx render core to make it more congruent with later versions (there are so many hacks in this that it would be a very lengthy undertaking to find and up-port them to a current Lynx, assuming it would even compile) and also add more GUI elements, but the biggest issue remained MacLynx's Frankenstein event loop. From "beta 2" to beta 3, I managed to cut down on unnecessary screen updates but the event loop still seems to be doing a lot, a probable impedance mismatch between Lynx's main loop which reasonably expects a terminal all to itself and bolting the classic Mac OS event loop onto that. (I wonder if Olivier was struggling with the same thing when he was working on it.) While working on this release I spun my wheels quite a bit trying to figure out where key down events were getting dropped or delayed while mouse events like clicks on links were seemingly unaffected, and ended up putting further work on it aside for awhile, which is why we're now into 2023.
Then it hit me: I had always intended to make MacLynx more Mac-like and use more Mac controls. In fact, beta 3 has a dialogue resource in it I did some initial messing around with but never hooked up. If moving more things into the native mouse-driven GUI makes it faster ... let's make it faster by moving more things into the native mouse-driven GUI! Time to dig out that well-worn hardcover copy of Inside Macintosh and dive in!
MacLynx runs on any 68K or Power Mac with System 7.0 or later, and MacTCP or OpenTransport. Let's fire it up on our clock-chipped 40MHz Quadra 800 under A/UX 3.1 (using the built-in System 7.0.1), with Crypto Ancienne 2.0 providing self-hosted TLS 1.3. Now, when you press "g" (or Shift-G) to G)o to a site, you don't type into the terminal display: you type into a real dialogue box. That means mousing, a proper cursor and proper edit controls. And it's faster! And what's this sorcery? The Lynx paginator is now wired into a real scrollbar! Even the thumb is live! It even works with scroll wheels if you use something like USB Overdrive. Implementation details in a minute. Yes, you can pass data from Lynx into the Mac GUI, including the current URL, and directly edit it. This works for many other places Lynx would ask for a string such as finding text in the document (forward slash). Escape and Return still work, so your muscle memory does too. Besides the scroll bar there's a <<< back "button" you can click on in the top left, and the shortcuts at the bottom of the screen in the default novice mode are all clickable also.All this works because part of Olivier's original concept was to shortcut certain operations in the Lynx main loop by feeding keys directly into it; I've just expanded on his basic notion. Doing so avoids a lot of code and is consequently much faster. Anything that can be turned into a Lynx keystroke, we can accelerate by intercepting those events in the Mac event loop instead. The "hot spots" work just by seeing where on the screen the hit occurred, and "pushing" the appropriate Lynx command key (back, go, options, etc.) directly into the Lynx main loop.
The scroll bar, despite being visually different, is in fact implemented using the same basic idea. Scroll bars in Mac OS are just controls and don't actually scroll anything in and of themselves. Instead, the code in Lynx that prints "page X of Y" in the top right corner is wired to call new Mac terminal handler code that sets up the scrollbar extents. If there's only one page, the scrollbar control is disabled. If there are multiple, the Mac terminal handler enables the scroll bar and sets the extent and proportional scroll thumb position according to the page you're on, so it's always current — even if you use the keyboard anyway. If you click on the up and down buttons, those get mapped to the up and down keys, and similarly if you click on the scroll bar above or below the thumb. If you drag the thumb to the top or bottom, Lynx is told to go to the beginning or end of the document.
The scroll bar is not perfect yet and I still need to do some more thinking on the design. Lynx does support scrolling by a couple lines or half a page at a time but this requires more bookwork than the relatively simple method used here, in particular to maintain the scrollbar thumb position. For that reason, you can't currently hold down the up or down scroll button to scroll multiple pages because it moves a whole page every go and a fast system would easily overshoot. (I do allow this with scroll wheels, since a clicky one can be controlled fairly precisely. I use a Microsoft LaserMouse 6000 with USB Overdrive on my MDD G4 and the scroll wheel works rather well with MacLynx.) You also can't drag the thumb to an arbitrary position in the document because Lynx doesn't know how to do that. If you drag it down but not all the way, it advances the page and snaps the thumb to the right place, and analogously goes back a page if you drag it up.
The dialogue box support was a little more complicated. There are many places Lynx requests a string from the user with a generic function LYgetstr, but not all these places are appropriate for a dialogue box (especially a modal one), and some of them need unique behavioural changes to translate them to the Mac's conventions. As such I wrote dialogue box code only for some hand-picked parts of the browser, specifically entering and editing URLs, entering and editing server query strings (primarily for Gopherspace: not used much on the Web anymore now that <isindex> is dead, but I still use it and the support is still there), and entering document search terms. The code differences are in whether text is carried over from Lynx (necessarily converting it from a C string to a Pascal string, so URLs are limited to 255 characters, sorry!), whether the text is pre-selected for you, and what keys are active. Special event handlers exclusive to their bailiwick trap salient keys with specific handling for Command-A to select all, and the cursor up and down keys are live in some places to move through previous entries (as well as Return/Enter and Escape, of course). The prompt Lynx provides is adopted as the dialogue box prompt, so no new bespoke strings were needed.
Here's the still-to-do list, more or less.
- What the heck with the event loop.
- Fix text alignment with <div>, especially with improperly centred text, and ensure the element is treated at block-level. Right now it seems to treat it more like a degenerate <span>.
- Add more ampersand entities to the HTML parser.
- Pull down menus to feed Lynx keys like the hotspots in novice mode. Olivier did some initial work on this but they aren't hooked up to anything. You should be able to use the pull-down menus at least for the functions shown on screen. While we're at it, add more Mac-like shortcuts for Command-F for find and Command-P for print, to the extent it prints anything. (Command-Q is of course already a thing, but it should be faster: see "what the heck with the event loop." File, Quit is of course instant.)
- While it wouldn't feel appropriate to pop a modal text requester for HTML form fields, you should be able to move about with clicking, which doesn't seem to properly work.
- Lynx's quit confirmation should be an alert or dialogue box of its own.
- The download prompt should be an alert or dialogue box of its own too.
- Smoothly feed images on clicks to something like JPEGView or QuickTime Picture Viewer.
- The options display should be mouseable.
No comments:
Post a Comment
Comments are subject to moderation. Be nice.