Archive for February 13, 2024

Tuesday, February 13, 2024

JuxtaCode 1.0.2

Yori Mihalakopoulos (Mastodon):

Easily trace your code’s history, so you can better shape its future. Browse commits, compare branches, see how a file has changed over time. Gain insights into tricky conflicts and resolve them with a powerful merge tool.


Access a file’s complete history by simply opening it. A dedicated tab will show all the relevant changes from the file’s inception to the latest commit (or your local changes if you’ve made a recent edit) even if the file has been renamed or moved along the way.

As with Kaleidoscope, this quick file history works with loose files. You don’t have to open the repository first. JuxtaCode is a file comparison tool, but it acts more like a Git client here in that as you move up and down the commit list it shows you the changes made in the selected commit, whereas Kaleidoscope is mored designed around your choosing two arbitrary versions to compare.

JuxtaCode detects conflicts and surfaces the information you need to track down the underlying causes. When it comes to making fine-grained edits, the powerful and adaptive 3-way merge tool helps you weave together code from each side of the conflict.

I haven’t had the need to use this yet. The app is $40 (no subscription) with a 14-day trial.


Split View Proactive Peek and Reveal on Edge Hover

Wade Tregaskis:

It’s easy to see how some UI designer thought this was a good idea. Surely if you move the mouse near the edge of the window (or the screen, in fullscreen mode) and rest it there, it’s because you’re looking forlornly for your lost sidebar? What could be more helpful and delightful than your missing sidebar popping into view?!

Unfortunately, they have ignored that fact that there is usually already other GUI controls at the edge of the window, not the least of which being the window edge itself (for drag-resizing of the window). Scrollbars are another common inhabitant of window edges.

“Proactive Peek” is the worst of these two because not only does it change what’s under the mouse cursor just as you’re likely to click, stealing the click away from its true target, but it actually shrinks the window’s visible contents. This leads to layout changes and motion noise, particularly in web pages where it can have knock-on effects like mucking with the scroll position or causing major changes by crossing some “responsive design” threshold.

Losing the sidebar is a real problem that people encounter and get stuck on. Maybe it wasn’t such a good idea to get rid of all the borders and chrome. Proactive Peek actually is kind of delightful, but there are some issues, as he mentions. For me, it changes the Safari toolbar layout. I also wonder whether it’s obvious enough or easy enough to trigger to really help people who are lost.

Bumping macOS’s Major Version Number

Jordan Rose:

There were four good moments for Apple to switch Mac OS version numbers from 10.X to 11 […] and they missed all of them, instead eventually tying it to the Apple Silicon switchover (what would have been 10.16).

I think about this a lot. They ended up doing it with macOS Big Sur, which had major interface changes in addition to Apple Silicon. The numbers are still out of sync with iOS, and macOS has a lower number even though it’s much older. I still see a lot of confusion from people, e.g. an app requires 10.13 or later and they have 12.0 and think it isn’t supported.


Dragging From a List With SwiftUI

Marco Arment:

I wish so badly that SwiftUI’s .onMove supported multiple-item selection in a List.

I should never need to tell my customers, “That was too difficult to achieve in SwiftUI, so that feature is gone.”

It’s scary reading stuff like this because, glancing at the API, the source is an IndexSet, so it seems like it was designed to handle multiple items. How are you supposed to know ahead of time that this doesn’t work? I was hoping to see someone reply, telling Arment what he was doing wrong, but instead there were two links to forum threads about list dragging being broken.

Tim Schmitz:

This category of problem still really concerns me about the future of Apple’s UI frameworks. There are some things that were possible in UIKit that just aren’t in SwiftUI, and Apple doesn’t seem too bothered by some of them.

This is basic stuff, not obscure features. The iOS and macOS interfaces make heavy use of lists and tables. And SwiftUI was introduced almost 5 years ago.


SwiftUI 5 feels mostly feature complete on the iOS side, but List keeps being hard for Apple to get right it seems. In terms of onDelete and onMove, they have improved a bit over the years but still problematic.

On the Mac side, I periodically take a look at Shortcuts to see how it’s doing. It still doesn’t support dragging and dropping shortcuts from the list into a folder in the sidebar (even if you only drag one). It does let me re-order a multiple selection, though it also lets me try when a sort is in effect, which of course doesn’t work. Whenever I click on something in the sidebar it loses the sort and goes back to the manual ordering. I don’t know what the thinking was here.


Update (2024-02-14): Rhett Rogers:

Every time I attempt to use a SwiftUI List, I think it is perfect.

Then I actually have to make something real and it almost always falls short whenever I have to do anything with custom colors or animations. And I fall back to a ScrollView { VStack {} }.

Helge Heß:

It would be ok if it would just affect customization, I just want the stuff that is builtin. But it’s flickering and has all sorts of other weird side effects (transitions etc).


I was converting a like 3y old SwiftUI app to List end of last year assuming that it should have gotten OK by now. Still the same mess (same for LazyVStack fwiw, so as you went back to ScrollView + non-lazy VStack).