Post

Replies

Boosts

Views

Activity

Bug: Finder/AppleScript interaction
I have created a simple AppleScript that makes a folder named with today’s date. For many years, it has worked fine except: If I run the script (from a script app in the menu bar), then dump files into the folder, then change the colored “Tag” on the folder, I get a Finder error - An unexpected error occurred (error code -8076) - and I have to force-quit the Finder to complete the color tagging. If it change the tag before dumping the files, no error occurs. (Please hold the “Doctor, it hurts when I do this …” jokes.) This error has persisted through many macOS major iterations, including Tahoe 26.4.1. Prolly a Finder bug, but not sure. Here’s the source, for anyone interested. set dateStr to getDate() --display dialog dateStr tell application "Finder" activate try --set thisFolder to (the target of the front window) as alias set thisFolder to (the target of the front window) as string make new folder at thisFolder with properties {name:dateStr as string} on error errMsg display dialog "ERROR: " & errMsg end try end tell on getDate() set theDate to current date set theYear to year of theDate as string set theNewYear to third character of theYear & fourth character of theYear set theMonth to month of theDate as number as string if length of theMonth = 1 then set theMonth to "0" & theMonth as string end if set theDay to day of theDate as string if length of theDay = 1 then set theDay to "0" & theDay as string end if return theNewYear & " " & theMonth & " " & theDay as string end getDate
3
0
192
3w
Scrolling bug with AVPlayerView in AppKit and PlayerView in SwiftUI
Using AVPlayerView with a running movie, the first scroll event (either direction), and only the first, resets the playhead to the start of a video, if it is the initial event the AVPlayerView receives - after that, the scroll wheel works as expected. This is a PITA when, e.g. after a third of the way through a movie, bumping the mouse wheel sends you back to the beginning. The bug also occurs notwithstanding the playhead is advanced in code with seekToTime(), or the scroll event is simulated with Keyboard Maestro - a wonderfully useful app for debugging and much more (no relation with the developer). Again, only for the first scroll event, and nothing else (see below) has happened. In AppKit, it is possible to intercept scroll wheel events. But one truly useful feature of AVPlayerView is mapping scroll events to the left-/right-arrow keys which provide frame-wise forward/reverse movement. You have to give that up if you intercept scroll events, and there's no way AFAIK to otherwise pass to AVPlayerView an "advance- or reverse-frame" message, at least not exactly the same amount as the scroll wheel does, except on first use. Similarly, I can't figure out a way to send a "forward-one-scroll-unit" event on initial video start to suppress the bug. The AVPlayerView j-k-l shortcuts might be useful for FCP users, but I could do without - alternatively, they should be remappable. If you use these keys before scrolling, or manually advance the playhead with UI, the bug evaporates. The only way to replicate it is to start playing video with the play button (or in code), then wait long enough that you can discern if the playhead resets, then triggering the scroll wheel (or double-swipe on trackpad) - either direction. Since the bug occurs only with the first scroll event, you have to close the AVPlayerView and repeat to replicate. A long debug cycle... Since the bug occurs with both AppKit and SwiftUI, I'm guessing that SwiftUI's PlayerView is just a convenience wrapper of the AppKit version. SwiftUI doesn't offer the developer an equivalent level of event control, which makes the problem even worse. This report applies to macOS; YYMV with iOS. I have seen similar reports earlier by searching for "Calling AVPlayer seekToTime: results in incorrect scrollWheel behavior".
0
0
1k
Feb ’22
Developer Documentation within Xcode is too small
On a big screen, Xcode Developer Documentation (from Xcode help menu) can read pretty small, especially the side bar, when you have low vision. At least the main pane can be enlarged with cmd-+, but it is not persistent. I usually end up closing it and looking up the info with a web browser, which is easier to move out of the way or send-to-back. Shouldn't there be a preference for setting this too ... or even better, just return to the last magnification used? Advance apologies if I simply couldn't find it in Xcode prefs. BTW, the "tags" function for this forum does not work well. Try typing "Xcode" in the search box then find a tag labeled "Xcode".
2
0
633
Feb ’22
Bug: Finder/AppleScript interaction
I have created a simple AppleScript that makes a folder named with today’s date. For many years, it has worked fine except: If I run the script (from a script app in the menu bar), then dump files into the folder, then change the colored “Tag” on the folder, I get a Finder error - An unexpected error occurred (error code -8076) - and I have to force-quit the Finder to complete the color tagging. If it change the tag before dumping the files, no error occurs. (Please hold the “Doctor, it hurts when I do this …” jokes.) This error has persisted through many macOS major iterations, including Tahoe 26.4.1. Prolly a Finder bug, but not sure. Here’s the source, for anyone interested. set dateStr to getDate() --display dialog dateStr tell application "Finder" activate try --set thisFolder to (the target of the front window) as alias set thisFolder to (the target of the front window) as string make new folder at thisFolder with properties {name:dateStr as string} on error errMsg display dialog "ERROR: " & errMsg end try end tell on getDate() set theDate to current date set theYear to year of theDate as string set theNewYear to third character of theYear & fourth character of theYear set theMonth to month of theDate as number as string if length of theMonth = 1 then set theMonth to "0" & theMonth as string end if set theDay to day of theDate as string if length of theDay = 1 then set theDay to "0" & theDay as string end if return theNewYear & " " & theMonth & " " & theDay as string end getDate
Replies
3
Boosts
0
Views
192
Activity
3w
Scrolling bug with AVPlayerView in AppKit and PlayerView in SwiftUI
Using AVPlayerView with a running movie, the first scroll event (either direction), and only the first, resets the playhead to the start of a video, if it is the initial event the AVPlayerView receives - after that, the scroll wheel works as expected. This is a PITA when, e.g. after a third of the way through a movie, bumping the mouse wheel sends you back to the beginning. The bug also occurs notwithstanding the playhead is advanced in code with seekToTime(), or the scroll event is simulated with Keyboard Maestro - a wonderfully useful app for debugging and much more (no relation with the developer). Again, only for the first scroll event, and nothing else (see below) has happened. In AppKit, it is possible to intercept scroll wheel events. But one truly useful feature of AVPlayerView is mapping scroll events to the left-/right-arrow keys which provide frame-wise forward/reverse movement. You have to give that up if you intercept scroll events, and there's no way AFAIK to otherwise pass to AVPlayerView an "advance- or reverse-frame" message, at least not exactly the same amount as the scroll wheel does, except on first use. Similarly, I can't figure out a way to send a "forward-one-scroll-unit" event on initial video start to suppress the bug. The AVPlayerView j-k-l shortcuts might be useful for FCP users, but I could do without - alternatively, they should be remappable. If you use these keys before scrolling, or manually advance the playhead with UI, the bug evaporates. The only way to replicate it is to start playing video with the play button (or in code), then wait long enough that you can discern if the playhead resets, then triggering the scroll wheel (or double-swipe on trackpad) - either direction. Since the bug occurs only with the first scroll event, you have to close the AVPlayerView and repeat to replicate. A long debug cycle... Since the bug occurs with both AppKit and SwiftUI, I'm guessing that SwiftUI's PlayerView is just a convenience wrapper of the AppKit version. SwiftUI doesn't offer the developer an equivalent level of event control, which makes the problem even worse. This report applies to macOS; YYMV with iOS. I have seen similar reports earlier by searching for "Calling AVPlayer seekToTime: results in incorrect scrollWheel behavior".
Replies
0
Boosts
0
Views
1k
Activity
Feb ’22
Developer Documentation within Xcode is too small
On a big screen, Xcode Developer Documentation (from Xcode help menu) can read pretty small, especially the side bar, when you have low vision. At least the main pane can be enlarged with cmd-+, but it is not persistent. I usually end up closing it and looking up the info with a web browser, which is easier to move out of the way or send-to-back. Shouldn't there be a preference for setting this too ... or even better, just return to the last magnification used? Advance apologies if I simply couldn't find it in Xcode prefs. BTW, the "tags" function for this forum does not work well. Try typing "Xcode" in the search box then find a tag labeled "Xcode".
Replies
2
Boosts
0
Views
633
Activity
Feb ’22