observeValueForKeyPath:... called too often in macOS 12
My app (macOS 12) observes a value in NSUserDefaults. Starting with macOS 12 observeValueForKeyPath:… is called at the start of the program, although nothing has changed yet. When the value actually changes, it is called twice. Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just return NSNull instead of old or new values. Any workaround for these multiple (and unnecessary) calls? Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: HandOff Problems
> On 13 Oct 2016, at 23:59, Gerriet M. Denkmann wrote: > >> On 13 Oct 2016, at 20:02, Charles Jenkins wrote: >> >> I don’t have any answers, but please keep us posted. Sierra is the first >> macOS upgrade that proved to be a complete disappointment to me, because the >> interesting new features are based on Handoff, which worked for me in >> Yosemite and El Cap, but now doesn’t work at all. >> >> Looks like Handoff is joining AirDrop and Siri as features that would be >> incredible if they worked… After long struggles with HandOff (a.k.a. NSUserActivity), I have now established the fundamental theorem of HandOff: It works, when it works. With the corollary: If not, then not. Sometimes, when macOS refuses to see hand-offs from iOS, it helped to change the Bunde Identifier of the iOS app, thus tricking macOS into thinking it got something from an altogether different app. But the more fundamental question: Is it possible to do HandOff from macOS to iOS (without iCloud, sharing documents etc.), just like one can do HandOff from iOS to macOS (using the userInfo to communicate some small data)? I tend to think this is impossible. Any proof to the contrary would be most welcome. Is there anybody on this list actually using HandOff? Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextView tab stop count
On 15 Oct. 2016, at 12:43 am, tridiak wrote: > > This works up to 12. Above that, it sticks to 12. Are you sure you're just not seeing them because the text in some columns is longer than you tab width? I just made a simple example with this: NSMutableAttributedString *mas = [[NSMutableAttributedString alloc] initWithString:@"\t1\t2\t3\t4\t5\t6\t7\t8\t9\t10\t11\t12\t13\t14\t15\t16\t17\t18\t19\t20\t21\t22\t23\t24\t25\t26\t27\t28\t29\t30"]; NSMutableParagraphStyle *style = [[NSMutableParagraphStyle alloc] init]; NSMutableArray* ma=[NSMutableArray array]; for (int t=0; t< 31; t++) { [ma addObject:[[NSTextTab alloc] initWithType:NSLeftTabStopType location:t*28.0f]]; } [style setTabStops:ma]; [mas addAttribute:NSParagraphStyleAttributeName value:style range:NSMakeRange(0,mas.length)]; [self.textView insertText:mas]; It works as expected. -- Shane Stanley , ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Getting/Setting FinderInfo attributes using native Cocoa API?
I ended up writing a category for NSManager to deal with this using the xattr.h APIs. Something like: - (NSDictionary *)PKG_extendedAttributesOfItemAtPath:(NSString *)inPath error:(NSError *__autoreleasing *)outError; - (BOOL)PKG_setExtendedAttributes:(NSDictionary *)inExtendedAttributes ofItemAtPath:(NSString *)inPath error:(NSError *__autoreleasing *)outError; On Thu, Oct 13, 2016 at 6:47 PM, Gary L. Wade wrote: > Write bugs for the ones where there's no non-deprecated method. I don't > recall all the values, but there may be UNIX-level functions to do some > things. And if there's no real way now, look up the info on the structures > and set them by way of the xattr calls. > -- > Gary L. Wade (Sent from my iPad) > http://www.garywade.com/ > >> On Oct 13, 2016, at 9:21 AM, Stephane Sudre wrote: >> >> No specific attributes in the FinderInfo data. I just need to be able >> to get it and set it on another file/folder. >> >> The labels case you mention is an interesting one. I had not thought >> about it when it comes to cross-compatibility with the different OS >> versions I need to support. >> >> On Thu, Oct 13, 2016 at 4:45 PM, Gary L. Wade >> wrote: >>> What attributes in particular do you need to work with? In case you might >>> be dealing with labels, those moved from the simple bitmask flag to >>> separate values in their own extended attribute. Other values may have >>> changed similarly but I haven't kept up with them. >>> -- >>> Gary L. Wade (Sent from my iPad) >>> http://www.garywade.com/ >>> On Oct 13, 2016, at 7:03 AM, Stephane Sudre wrote: Question: Is there a native Cocoa API that can replace the FSGetCatalog/FSSetCatalog API when it comes to retrieving/setting the FinderInfo (and FinderExtInfo) attributes of a file? OS X 10.8 and later. Problem: The FS CoreCarbon APIs are deprecated but apparently, there's nothing to replace them completely in Cocoa (Foundation). The NSURL resources APIs does not support the FinderInfo attributes (no obvious key in the broken documentation and using "com.apple.FinderInfo" does not work). Workaround: This can be worked around by using the xattr.h APIs but if it could be possible to avoid this, it would be better. >> >> >> >> -- >> Packaging Resources - http://s.sudre.free.fr/Packaging.html > -- Packaging Resources - http://s.sudre.free.fr/Packaging.html ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextView tab stop count
> On Oct 14, 2016, at 6:43 AM, tridiak wrote: > > How does Xcode & Text Wrangler pull it off? Xcode pretty heavily customizes the Cocoa text engine; even back in the ProjectBuilder days they had a bunch of custom editing subclasses. I wouldn’t be surprised if they implement their own tabbing for efficiency, since obviously the docs it works with include a bazillion tab stops. Text Wrangler doesn’t use Cocoa’s text system at all. It’s a variant of BBEdit, which has been around since the early ‘90s so it must have its own text engine. I’m surprised that there would be some arbitrary limit like 12 tab stops on a line. That sounds like something to file a bug report about. All they need is to change “kMaxTabStopsPerLine” to a bigger number like 100, right? :-p —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSTextView tab stop count
Why can’t I use more than 12 tab stops in NSTextView (enclosed by a standard NSScrollView)? I can use less, but I need significantly more. Is it to do with the ruler? NSMutableParagraphStyle *style = [[NSMutableParagraphStyle alloc] init]; NSMutableArray* ma=[NSMutableArray array]; for (int t=0; t< some large number; t++) { [ma addObject:[[NSTextTab alloc] initWithType:NSLeftTabStopType location:t*28.0f]]; } [style setTabStops:ma]; [mas addAttribute:NSParagraphStyleAttributeName value:style range:{0,mas.length}]; This works up to 12. Above that, it sticks to 12. Applying something similar directly to the NSTextView paragraph style has the same problem. How does Xcode & Text Wrangler pull it off? TIA Mark ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Font alignment when using bold variant of system font
Just in case anyone finds this thread and wonders what the solution was, here it is: - (void) updateEditorHighlighting: (NSString*)expression { NSTextView * editor = (NSTextView*)[self currentEditor]; [self updateExpressionValue:self.stringValue into:editor.textStorage]; // This fixes a strange issue where the vertical alignment of the font is a bit strange during editing. NSMutableParagraphStyle * paragraphStyle = [[NSMutableParagraphStyle alloc] init]; paragraphStyle.maximumLineHeight = [editor.layoutManager defaultLineHeightForFont:self.font]; [editor.textStorage addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:NSMakeRange(0, editor.textStorage.length)]; } On 13 October 2016 at 13:26, Samuel Williams wrote: > That's crazy, how can Apple make a system font which breaks existing apps!? > > On 13 October 2016 at 12:19, Steve Mills wrote: > >> > On Oct 12, 2016, at 16:55, Samuel Williams < >> space.ship.travel...@gmail.com> wrote: >> > >> > It's the standard font "San Francisco" from Apple. That's odd that it >> would >> > be buggy like that. I'll try what you suggested. >> >> Not surprising. The new San Francisco is pretty bad. >> >> Steve via iPad >> >> >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/space. >> ship.traveller%40gmail.com >> >> This email sent to space.ship.travel...@gmail.com > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com