Let's say I have a NSTextView embedded in a NSClipView and NSScrollView. Let's say that the application using this NSTextView is run in a right-to-left (RTL) language. Let's say that because the text visible in the text view will always be LTR, the text view alignment is forced to left instead of the default natural setting and that this text is big enough to require a vertical and horizontal scrollers. What I'm experiencing so far is that AppKit will scroll the NSTextView to the top right corner. Which would make sense if the contents of the textview was RTL. But it is not. I looked at the documentation, headers, tried playing with a subclass of NSScrollView and play with the tile method, with the userInterfaceLayoutDirection property of the scrollview. No success so far. [Q] How do you tell NSScrollView or NSTextView that the default scroll position is the top left corner and not the top right corner in such a case? Environment: macOS 10.14.6 ; AppKit ; Objective-C (if that matters)

[Q] How is it possible to order the %@ parameters correctly when using both LeftToRight text and RightToLeft text in the same string? Context: this needs to work for the title of a NSMenuItem. In English, I have the following format string: @"%@ - %@" and I use the following code: NSString *myString = [NSString stringWithFormat:@"%@ - %@", @"LTR Text", @"LTR Other Text"]; Which results in @"LTR Text - LTR Other Text". In a RightToLeft language, the @"LTR Other Text" string is going to be a "RTL Other Text". And I would like the result to be: @"RTL Other Text - LTR Text" I tried playing with 1$ and 2$, it did not work. @"%2$@ - %1$@" results in @"LTR Text - RTL Other Text". I tried using stringByAppendingString: or Format: to force the ordering. It does not work. The "LTR Text" string ends up in the middle of "RTL Other Text". I tried using the ^0 or 0^ keywords apparently used by the Finder. But this is not supported by the standard Cocoa API. This is on macOS 10.14.6 where support for RTL text is not good in Xcode v10.1 text editors when it comes to text selection, copy-paste, and typing.

I have a NSRulerView with a vertical orientation. It works fine from macOS 10.13 to 11.x. In macOS Monterey (12.2.1 here), the ruler view is not receiving drawHashMarksAndLabelsInRect: messages when the associated NSTextView is scrolled vertically. When the parent NSScrollView is resized, the ruler view is correctly refreshed on all macOS versions. [Q] Is it a known bug in macOS Monterey?

3 questions on the AppleArchive.h APIs: Are there Obj-C APIs? I see Swift APIs but I'm not looking forward to using them. Is there sample code showing how to use the C APIs? Is there any plan to fix the documentation on Apple Developer web page for this library? It's not really useful right now and the CSS is broken for sample code (the sample code frame is clipping code on the right). Same problem with the Compression documentation.

Optimal height = height that displays all the rows such that you can't scroll the tableview vertically (assuming elasticity is set to none). On macOS Catalina and earlier, the optimal height for a headerless NSTableView is: number of rows * (height of row + height of intercell spacing) On macOS Big Sur and later, it looks like to be: number of rows * (height of row + height of intercell spacing) + 20 [Q] Why do we have to add an apparently pointless 20-pixel high white space at the bottom of the NSTableView in macOS Big Sur and later? This is rather annoying and breaks controls/views spacing.

Please note I have already seen the answers pointing to the audit_token. From what I'm observing, the audit_token does not return the pid from a NEFilterFlow but actually returns the epid. For instance, if Safari is sending a HTTP GET request and the server name of the URL needs to be resolved, mDNSResponder will resolve the URL on behalf of Safari. In this case, the debug info for the NEFilterFlow shows that: the procPID for the flow representing the UDP communication to port 53 is the one of mDNSResponder. the eprocPID for this flow is the one of Safari. If you use the audit_token of the sourceApp, you will end up with the eprocPID: the Safari one. Which makes sense since it's the audit_token for the sourceApp. But, IMO, it's not the pid of the network flow. There is obviously a non official API to retrieve the eprocPID value since Objective-C is the nice language that lets you retrieve that kind of info easily. The issue is that this is quite probably not considered as safe/secure as the way you get the eprocPID through the audit_token. So: [Q] How are we supposed to get the real pid from a NEFilterFlow?

The new .ips format does not seem to provide a way to know whether a binary is part of macOS. Ref. https://developer.apple.com/documentation/xcode/examining-the-fields-in-a-crash-report [Q] Is it really the case? If it's not part of the information inside a .ips file, how is it supposed to be determine now? loadAddress ranges? Just asking for a friend.

Let's say you have a NSTextField label. Let's say you have attached a formatter to the NSTextField. Let's say the formatter may not return the same string for the same object depending on the time of the day. [Q] How do you force the refresh the string displayed by the NSTextField when you provide the same object value over time? So far, I've only found an ugly solution: call setNeedsDisplay:YES when I set the object value. I'm looking for a more elegant solution. An example illustrating the "issue". The MainMenu.xib file contains a NSWindow with a NSTextField. When the [_label setNeedsDisplay:YES]; line is uncommented, the displayed NSTextField string is refreshed every 5 seconds as expected. Otherwise, it's not. #import "AppDelegate.h" @interface MyFormatter : NSFormatter @property NSUInteger counter; @end @implementation MyFormatter - (nullable NSString *)editingStringForObjectValue:(id)inObject {     if (inObject==nil)         return @"";     if ([inObject isKindOfClass:NSString.class])         return inObject;     if ([inObject isKindOfClass:NSAttributedString.class]==YES)         return ((NSAttributedString *)inObject).string;     return @""; } - (NSString *)stringForObjectValue:(id)inObject {     if (inObject==nil)         return @"";     return [NSString stringWithFormat:@"%lu",(unsigned long)self.counter]; } #pragma mark - - (BOOL)getObjectValue:(id *) outObject forString:(NSString *) inString errorDescription:(out NSString **) outError {     *outObject=[inString copy];     return YES; } @end @interface AppDelegate () {     IBOutlet NSTextField * _label;     MyFormatter * _formatter;     NSTimer * _timer; } - (void)updateFormatter:(NSTimer *)inTimer; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {     _formatter=[MyFormatter new];     _label.formatter=_formatter;     _label.objectValue=@"objectValue";     _timer=[NSTimer scheduledTimerWithTimeInterval:5                                             target:self                                       selector:@selector(updateFormatter:)                                           userInfo:nil                                            repeats:YES]; } - (void)updateFormatter:(NSTimer *)inTimer; {     _formatter.counter++;     _label.objectValue=@"objectValue";     //[_label setNeedsDisplay:YES]; } @end

I'm currently using sizeThatFits to know the ideal dimensions for a NSPopUpButton (with no bezel). In macOS Mojave and Catalina, the size I get is correct. In macOS BS, the size is incorrect: the width is not big enough to display the title. the height is too small and the text is not vertically centered. Questions: is sizeThatFits a unreliable API? if it is which one should be used? I don't want to use sizeToFit because I may need to resize the popup button once I know all the idea sizes. Note: I have absolutely no plans to use autolayout.

In macOS Big Sur, the dimensions of the NSSearchField control have changed. For the worst, of course. Previously, in macOS Mojave or Catalina, when using a small NSSearchField control, you could replace the magnifier icon with a custom icon using: a 13x13 (26x26 @2x) image. the setSearchButtonCell: API as suggested at https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/SearchFields/Articles/CustomizingSearchFields.html#//apple_ref/doc/uid/20002246-BABFIBIA Now in macOS Big Sur, a 13x13 image is: a little too big drawn over the top of the bezel of the search field. Trying smaller size does not solve the fact that the image is offseted to the top of the control and is drawn over the bezel. As there are no offset properties for NSButtonCell, maybe the issue could be fixed with an image whose contents is incorrectly centered. But I'm not in the mood to try this right now. Questions: Is this a known bug? If this can be solved by using a specific image size, what is this size for a small NSSearchField? If this can be solved by playing with the searchButtonRectForBounds: method, what is the specific rect that should be returned?

I have a NSTextView enclosed in a NSScrollView > NSClipView. The NSScrollView has a vertical NSRulerView. The NSTextView is configured to disable text wrapping, so for long and wide texts, there are both a horizontal scroller and a vertical scroller. Problem: When the text view is scrolled up or down using the page up or down keys, the text is correctly scrolled up or down BUT it is also scrolled to the left. Basically, it's also scrolled to the left as if there was no vertical ruler. Before the page down scroll: ---+----------------------------+-+ |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,|-| |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 | Lorem ipsum dolor sit amet,| | |	 +--+-------------------------+-+---+--+-------------------------+-+ After the page down scroll: ---+----------------------------+-+ |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con|-| |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con|-| |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 | m ipsum dolor sit amet, con| | |	 +--+--+----------------------+-+---+--+--+----------------------+-+ The next page down or page up scroll will not scroll the text horizontally. I looked into the different APIs related to scrolling in NSView, NSScrollView, NSText, NSTextView and my guess would be that the problem happens when the scrollToPoint: method is run for the NSTextView because of an incorrect convertPoint: fromView: conversion. BTW, switching between contiguous and non contiguous for the NSTextView does not fix the issue. I have not found any WWDC session so far that would deal with that issue (WWDC 2010 Session 214 does not AFAIK). Google Search, Stack Overflow are clueless. Of course, this issue does not happen when the NSTextView wraps text. There is no horizontal scroller in this case. Question: How can you prevent NSTextView from scrolling incorrectly in this case?

macOS 10.14.6, Non Retina Apple Cinema Displays (both the 27" and the terrific 30").  Problem: I'm observing 2 different text rendering results depending on whether the text is drawn in a NSTextField or a NSTextView. In both cases, the font, text, foreground and "background" colors are the same. The background color is black. The foreground color can be white, red, gray or green. The NSTextField is located in a NSTableCellView, does not draw its background. The background color is defined in the NSTableView. In the NSTextView, the text looks good. In the NSTextField, the text does not look good (either the glyphs are thinner or the color is not as accurate). I'm not saying this is totally surprising. But I would like the NSTextField(Cell) rendering to be as good as the NSTextView one. Solutions already tested: looking for a solution on SO. One result where someone wanted the opposite : NSTextView to render the same way as NSTextField. So, nope. subclassing NSTextFieldCell: This case is interesting. If you subclass NSTextFieldCell and override: (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView *)controlView so that it just calls the super method, then the text rendering is different than the NSTextFieldCell one. If you just subclass NSTextFieldCell and do not override any method, then the rendering is the same as the NSTextFieldCell one. So there must be some code in AppKit to render text differently for a NSTextFieldCell if some of the drawing methods are not the original ones. When overriding - drawInteriorWithFrame:inView: and aplying some changes to the context with: the text drawing mode antialiasing font smoothing font subpixel quantization I have not been able to reproduce the rendering of NSTextView. Yet, imagining a function to set the font smoothing background color existed, this would provide a rendering closer to the NSTextView one. But of course, this is just pure imagination. 3. setting the background color of the NSTextField(Cell) to background color of the tableview and set drawsBackground to YES: This does not help if you do not subclass NSTextFieldCell and override the drawing methods. If you do, then the text rendering is closer to the one in NSTextView but the issue is that when you select the row, the background of the NSTextField(Cell) is drawn over the highlrow selection rect. Playing with a custom NSTableRowView to fix this led to no results so far. Question: How can you make a NSTextField render text like NSTextView when the NSTextField does not draw its own background?