I use `claude -p` interactively -- I understand why they put it under this new umbrella, but having to open the fullscreen interface each time to not be counted as a programmatic tool is a little disappointing.
> I was doing this bit using a capture card and Photo Booth on macOS which doesn’t actually support disabling the image-flip on the video feed
I use OBS to monitor my video capture. This essentially lets me use my Mac as a monitor for my headless desktop (which does not have a monitor of its own). Maximum gaming.
Deskflow lets me use my Mac as a keyboard over LAN, too. Beats remote desktop for sure. Especially when gaming.
My preferred way is ffplay(1). Last time I checked I get lower latencies than OBS at that, at least when I use `-sws_flags fast_bilinear`, which is the same scaling OBS uses by default.
I wouldn't wish bilinear scaling on my worst enemy; 1:N is the only way to go for me. I'll check out ffplay.
Edit: ffplay doesn't support cropping the output to fit my display (or if it does, it's far too arcane for me). As composable as ffmpeg is, it's awful UX for me. I'll stick to OBS.
Use whatever gets the job done. As for scaling and cropping, to the best of my knowledge, ffplay(1) supports all the options that ffmpeg(1) does. Here is what I for example use when capturing my Famicom: ffplay -sws_flags fast_bilinear -framerate 60 -video_size 1920x1080 -vf crop=iw-360:ih,scale=-1:1080 $DEV.
Scrolling is perfectly smooth when you use a trackpad. IMO, clickwheels are a legacy technology for scrolling (even when I use Windows, I left-hand a Magic Trackpad so I still have smooth analog scrolling).
I never liked trackpad. I am an avid RTS player, the mouse is by far the superious input device.
Besides, I never work on a laptop.
And this is a lame excuse. Smooth scrolling should also work when using keyboard with and pageup/pagedown, at least as an option and with some tuning preferences.
Smooth scrolling also worked on the Amiga Cygnus Editor in 1986 - yes, 40 years ago - on a computer with 512Kb RAM and a ~7MHz 68000 CPU, and from keyboard too. And Zed complains at launch if it doesn't find a suitable Vulkan GPU driver, since the fallback CPU driver does not provide a smooth enough experience, despite 4-5 orders of magnitude more RAM, and a ~3 orders of magnitude faster CPU, than a 40 years old Amiga...
Isn’t this just a case of not wanting to or having the resources to maintain a fallback renderer?
Supporting basically-compliant Vulkan GPUs covers probably 99.9% of developer machines. You need a pretty big user base to make it make sense to support the last 0.1% of people without access to a proper GPU driver.
I hope Zed reaches that scale, since I really like the project. But right now I would be a bit disappointed if that was a priority.
"smooth scrolling" with a mouse or keyboard like you mentioned is a lie. Its animating movement but is not precision input at all. its "smooth" sure but you have zero control over the actual scroll (i do wish zed did this too its genuinely useful as an accessibility aid because it lets your eyes follow where the cursor ends up for example but yeah its not the same as having proper precision input for scrolling as you do with a touchpad). I do agree a mouse is far better at precision input wrt pointing at things but when programming,,,, you do not need to be so precise with cursor movement. you're editing text which is largely keyboard centric, and the time offset between moving your hand from a mouse to a keyboard on a desktop is in my opinion far higher than it is to move your hands from a keyboard to a touchpad surface. Not to mention you get actual precision with scrolling with a touchpad. I personally keep both a proper MMO mouse with a dozen programmable buttons on my desk, and a apple touchpad with precision drivers for normal use.
also wrt scrolling, mice like the logitech mx master actually have what is in my opinion a much better solution where the scrollwheel is not stepped and has scrolling inertia, allowing you to have the same level of precision with scrolling as you do with a touchpad (im not sure if the vertical wheel on it is the same but regardless). Its in my opinion a similar jump in capability for mice as continous triggers were for game controllers. Something that must have been initially quite notable, but slowly became expected behaviour (except on the switch for some reason but whatever i guess)
macOS is a whole thing in terms of smooth scrolling, or HID (human interface devices) in general. It seems like Apple just doesn't put a lot of effort in terms of working with third-party HIDs:
* There's a standard way to enable high-resolution scroll reporting (pixel-level instead of line-level), but Apple doesn't use it.
* There's a standard approach to multi-touch digitizers/trackpads (documented and I think to some extent created by Microsoft, called PTP) which Apple doesn't support.
* Apple's own Magic Trackpad speaks a proprietary protocol and it appears you can only speak it if you claim to use their USB VID/PID. And I don't think doing that would go over well in a commercial product. (And if you do manage to speak it, it turns out their driver really doesn't do two-finger scrolling well with tiny trackpads anyway. They probably only tested it on the generous dimensions of their hardware.) (Also, it attaches to your entire device, so having an additional interface with a different driver doesn't appear to work either.)
But...you can inject smooth scrolling events via Core Graphics. So you can run a userspace program with accessibility permission that scrolls smoothly. And you can also communicate with USB devices from such a program. There are some existing programs for doing smooth scrolling with standard mice (Mac Mouse Fix is one). I'm writing a userspace driver for PTP to make my keyboard's built-in trackpad work properly.
Last I checked, high-resolution scroll reporting over USB is not based on pixels but on fractions of a detent, which is annoying to say the least. Apple probably also didn't want to translate multitouch to scroll in hardware, since scrolls are not reported the same in all contexts (e.g. applications can choose whether it locks to an axis; which axes it can lock to depends on the capabilities of the view; etc.)
> But...you can inject smooth scrolling events via Core Graphics.
Applications can choose to ignore synthetic events, IIRC. Probably not an issue for scrolling, but for instance Little Snitch can be configured to ignore synthetic inputs to its security settings.
> Last I checked, high-resolution scroll reporting over USB is not based on pixels but on fractions of a detent, which is annoying to say the least.
I'd just be happy if it let me use the multiplier; don't care if it's not exactly pixels.
> Apple probably also didn't want to translate multitouch to scroll in hardware,
That much doesn't seem unique to Apple; both Windows and Linux appear to prefer accepting raw multitouch data.
> since scrolls are not reported the same in all contexts (e.g. applications can choose whether it locks to an axis; which axes it can lock to depends on the capabilities of the view; etc.)
I don't think they're actually taking advantage of this. My MBP's built-in trackpad will lock into pinch/rotate gestures when the cursor's over say Zed or iTerm2. (Zed's a bad example actually, as it has no accessibility tree to speak of. But I think it will lock into pinch/rotate anywhere.)
And for my own app, as far as I know (I'd be very happy to be corrected) there's no way to inspect a view to know what kinds of gestures it supports. It certainly would be nice to eliminate the possibility of locking into pinch/zoom in a place where that's meaningless but I don't see a way to do it.
> Applications can choose to ignore synthetic events, IIRC. Probably not an issue for scrolling, but for instance Little Snitch can be configured to ignore synthetic inputs to its security settings.
Yuck. I'm doing everything this way, including cursor movement and taps. I hope I don't come across such an app/configuration.
Used to have a mouse that had a scroll wheel that would toggle if it did the clicking motion or a smoother scrolling motion, I loved that one. I use Trackbals now, so if I need to scroll drastically I use the sidebar. Source Code map sidebar is the best though.
Apple's ID verification failed for me and I am now banned for life. There is no opportunity to appeal this or to ever participate in the Developer Program for me. Which sucks because I am now permanently locked out of developing seriously for any of the Apple ecosystem, ever.
I find it ironic that Apple did the whole silicon thing to get away from Intel and now they are reportedly crawling back to Intel? I hope M6 and beyond continue to be competitive for inference.
This is about FABs and not chip designs. Imagine a parallel universe where Apple was sourcing AMD chips (they actually did for graphic cards) and then went to TSMC to whom AMD is also a customer.
Note that I said M6 and beyond. I know the chip designs being produced will remain Apple's.
Other commenters in the thread talk about how Intel's node is simply inferior to TSMC's and will bottleneck the performance of the same chip designs simply by being bad. I hope that is not the case and/or that I won't have to settle for an Intel node inside my Apple chips. (They better not try to pull an AMD where some chips simply have utterly kneecapped performance for no good reason.)
reply