Toni Sagrista Selles (Hacker News):

In a dramatic turn of events, the Chromium team has reversed its Obsolete tag, and has decided to support the format in Blink (the engine behind Chrome/Chromium/Edge). Given Chrome’s position in the browser market share, I predict the format will become a de factor standard for images in the near future.

[…]

I’ve been following JPEG XL since its experimental support in Blink. What started as a promising feature was quickly axed by the team in a bizarre and ridiculous manner. First, they asked the community for feedback on the format. Then, the community responded very positively. And I don’t only mean a couple of guys in their basement. Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita, and many more. After that came the infamous comment[…]

[…]

To top it off, a couple of weeks ago, the PDF Association announced their intent to adopt JPEG XL as a preferred image format in their PDF specification.

Michael Larabel (Slashdot):

JPEG-XL image support is back in the very latest Google Chrome/Chromium codebase. Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support.

Luca Versari et al. (via Jarek Duda):

We’re excited to announce that Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155. JPEG XL is a next-generation image format designed to meet the needs of modern web developers and photographers. It offers 30-50% better compression than JPEG, lossless compression, built-in HDR support, lossless JPEG transcoding, and more.

In general, we recommend trying both AVIF and JPEG XL to get the best results. We expect that JPEG XL is most helpful for high-fidelity or lossless compression, especially of photographic images or in cases in which fine-grained progressive decoding is preferred.

Previously:

• Chrome Doesn’t Support JPEG XL
• iPhone 16 Adds JPEG XL

Rosyna Keller:

FruitMenu Redux revives a utility (FruitMenu) that brings lost Mac OS Classic features to Mac OS X. Specifically, it restores the fully customizable Apple menu.

It’s no longer a haxie that works by patching the operating system. Now, it’s a regular app that hooks into other apps (e.g. to switch to a particular window) using the accessibility APIs.

The first step was to implement every FruitMenu feature that’s still possible in the current macOS security environment. That immediately ruled out features requiring patching menus (sigh, I really miss patching menus) and features that require privileges now gated behind restricted entitlements. I also added support for viewing and executing Shortcuts.

[…]

Additionally, you can set a hotkey to any item you add to FruitMenu Redux!

[…]

Because SwiftUI doesn’t support dynamic menus, I had to rewrite all the menu code to use AppKit’s NSStatusItem and NSMenu as NSMenu is now a first-class citizen on macOS and fully supports dynamic submenu building. This means that FMR doesn’t even try to build the contents of a folder under you actually attempt to show the contents of the folder. Not only is this significantly faster, but it also uses significantly less memory.

FruitMenu is now available (Mastodon):

A built-in visual editor displays your menu on the left and a library of over 30 item types on the right. You drag items from one to the other (almost like Font/DA Mover, the best UX ever created). The library includes files and folders, submenus, Running Applications (and you can enable an option to show open windows and tabs), Mounted Volumes, Recent Items, Force Quit, Sleep, Restart, Shut Down, Shortcuts, Software Update, separators, System Settings panes, and more!

Anything you put in the FruitMenu Redux Items folder in your Library also appears in Files, folders, and aliases.

$10 (with $7 intro price), not in the Mac App Store because of accessibility.

Rosyna Keller:

OMG, Core Transferable, why do I have to declare a public UTI in my info.plist for internally dragging from one list in my app to another list in my app?! It’ll never be decoded by another app!

This was the fix to a bug I reported. With the new SwiftUI drag API, you apparently have to declare private internal drag types in your plist (on Tahoe, but not on Golden Gate).

Xounds, which plays sounds in response to user interface actions, is also back. Unlike FruitMenu, this one never appealed to me—I actually prefer to have the audio muted most of the time. I do find it interesting that it supports the old sound set files from Mac OS 8. Apple dropped the APIs for playing these way back during the 64-bit transition, but Xounds knows how to extract and play the audio.

Previously:

• SwiftUI in appleOS 27
• Where Did SwiftUI Leave You Hanging?
• Dragging From a List With SwiftUI
• Add Security Access Groups for Accessibility APIs
• Menu Master 1.0

I haven’t seen it documented, but it looks like Flickr went back to shipping its rewrite of the app. It’s better than before but loses the scroll position when going from an individual photo back to the grid.

Previously:

• Flickr 5.0