User Profile

What do I miss here? root@MacBook-Pro /tmp # sw_vers ProductName: macOS ProductVersion: 13.6.1 BuildVersion: 22G313 root@MacBook-Pro /tmp # log config --mode "level: off" root@MacBook-Pro /tmp # log config --status System mode = INFO root@MacBook-Pro /tmp # log config --mode "level: debug" root@MacBook-Pro /tmp # log config --status System mode = DEBUG root@MacBook-Pro /tmp # log config --mode "level: off" root@MacBook-Pro /tmp # log config --status System mode = DEBUG

Our application (which happens to run in an admin account, thus there's no problem authenticating) collects logs calling /usr/bin/log through NSTask. Usually this works all right, but sometimes all we get is the header Timestamp Thread Type Activity PID TTL and nothing else. The tool finishes with a zero result code, we get nothing on stderr and just the header above on stdout, with a proper EOF (as determined by a zero-length availableData read from an NSFileHandle through the stdout pipe). At the same moment, if the /usr/bin/log tool is run manually in a Terminal window with precisely the same arguments in the same user account the application runs in, we get the logs all right. Any idea what might be the culprit and how to fix the problem? Thanks!

Our application is a login item which runs inactive in background, and in some cases, it shows its popovers in NSModalPanelWindowLevel over a window of an (unrelated) active application. That works well and without a glitch for years. Now we'd like to change the mouse cursor when the mouse is over some subviews of our popover. Is there a way to do that? I've tried essentially all the cursor-related APIs I know of, from the most obvious cursorRects through trackingAreas up to the low-level explicit NSCursor.push/set, but whatever I do, looks like macOS simply ignores it and keeps showing the arrow default cursor, even though the mouse is over our window whose views have proper cursorRects or explicitly call NSCursor.push/set etc. Is there a trick to change the cursor in this case? Thanks!

Our app suite supports autofill through the ASCredentialProviderViewController API, and it works well. We would like though to be also able to record a new login/password when the user enters them directly in his web browser, so that we can offer the pair for autofill the next time he opens the same page. Is there any API for that? Perhaps I'm just blind, but I can't find any. Thanks!

Hi there, the documentation explicitly says this is what's contentView for. I've just tried and found big problems not adding — works like a charm — but positioning my view so that it does not clash with the standard ones. I've added a small badge at the rightmost edge of contentView. Having added the subview into contentView (in tableView:cellForRowAtIndexPath:, after checking that it does not exist yet in a reused cell view), I set up constraints so that it is Y-centered and sticks to the right edge of the contentView, that was very easy and worked nicely at the first try: UILayoutGuide *lg=cell.contentView.layoutMarginsGuide; [badge.trailingAnchor constraintEqualToAnchor:lg.trailingAnchor].active=YES; [badge.centerYAnchor constraintEqualToAnchor:lg.centerYAnchor].active=YES; I've found though if the text in textLabel (I have to address iOS12+, thus I can't use content configurations) is long enough, it clashes with the badge instead of clipping/wrapping/whatever it is set to (wrapping in my case). Thus I've added another constraint which makes sure the trailing edge of textLabel does not exceed the leading edge of my badge: UILayoutGuide *blg=badge.layoutMarginsGuide; [cell.textLabel.trailingAnchor constraintLessThanOrEqualToAnchor:blg.leadingAnchor constant:-6].active=YES; Oops: that pushed the badge right, so that it overlaps the accessory area. By my further testing, seems the culprit is another constraint (probably created dynamically later from the autoresizing mask) which bounds the right edge of textLabel to the right edge of contentView. I've tried to find and remove (deactivate) it in tableView:cellForRowAtIndexPath:, in vain, well, makes some sense perhaps, too soon. I've tried to find and remove it in tableView:willDisplayCell:forRowAtIndexPath:; no luck either. To me, this does not make sense at all. (It sort of looks like the documentation claim “After the delegate returns, the table view sets only the alpha and frame properties, and then only when animating rows as they slide in or out” is highly overstated. Self-evidently, non-trivial layout stuff happens after the delegate returns, but before the cell is drawn.) Eventually, having used updateConstraints explicitly (which does not feel right), I succeeded to find the darn thing, a fixed width constraint for textLabel. Tried to deactivate it: does not work, setting its active property to NO does nothing, no warning, no error, no exception, thing just stays at YES. I've tried to decrease its priority, that's even more funny: it goes down, when checked, it is down, but 1000 is somehow re-surrected after tableView:willDisplayCell:forRowAtIndexPath: returns, but before the cell is finally laid out and drawn. Ick. What's the proper solution of this? I suppose it should be pretty easy, but it is not, or I must be overlooking something pretty obvious. Thanks!