Re: Unhidden subview outside of superview's bounds
> On Sat 10.02.2024, at 11.16, Dragan Milić via Cocoa-dev wrote: > > Hello all, > > I’ve finally changed my main development platform to macOS 14 Sonoma and > almost immediately have I encountered something I consider being a bug. I > searched for similar issues, but nowhere have I found any relevant > information or help. As someone has notified me (without posting here as well), this is the consequence the default value of property “clipsToBounds” of NSView being changed from YES to NO in Sonoma SDK. Thanks Pierre again! -- Dragan ___ 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
Unhidden subview outside of superview's bounds
Hello all, I’ve finally changed my main development platform to macOS 14 Sonoma and almost immediately have I encountered something I consider being a bug. I searched for similar issues, but nowhere have I found any relevant information or help. The issue is rather funny; if you have a subview and, for whatever reason, it finds itself outside of its superview’s bounds, it remains visible, instead of being hidden. It’s like you have a window on your room wall, but still the interior of your room is visible outside of window’s borders :-) Here’s a simple Xcode project that explains what I’m talking about: https://zigz.ag/temp/SubviewBug/UnhiddenXcodeProject.zip Unpack and build this project, run the test application and see it yourself. However, there are some differences, regarding the Xcode/SDK version used to build the application and the macOS version it runs on. The project format is “Xcode 13.0” and " MACOSX_DEPLOYMENT_TARGET = 13.0”. Here you can find application bundle, build with Xcode 14: https://zigz.ag/temp/SubviewBug/UnhiddenXcode14Build.zip The relevant build parameters, as found in application's Info.plist are: BuildMachineOSBuild: 22G605 DTPlatformVersion: 13.3 DTSDKBuild: 22E245 DTXcode: 1431 DTXcodeBuild: 14E300c If you run it on both Ventura and Sonoma, you’ll see ti behaves as expected. However, here you can find application bundle, build with Xcode 15: https://zigz.ag/temp/SubviewBug/UnhiddenXcode15Build.zip The relevant build parameters, as found in application's Info.plist are: BuildMachineOSBuild: 23D56 DTPlatformVersion: 14.2 DTSDKBuild: 23C53 DTXcode: 1520 DTXcodeBuild: 15C500b Now, if you run this build on Ventura, you’ll see it behaves fine. Running it on Sonoma however, shows the behaviour I’m trying to explain; the ratio button titled “Two” remains visible, even though its superview shrinks and it goes out of its superview’s bounds. So, the issue is present only on Sonoma, if build with Xcode 15. The difference is visible even inside Interface Builder. Here is a short video of shrinking a superview in IB of Xcode 14, note how the “Two” radio button becomes invisible, as it goes outside of its superview’s bounds: https://zigz.ag/temp/SubviewBug/InterfaceBuilderXcode14.mov Here is the video of shrinking the same superview in IB of Xcode 15, the “Two” radio button remains visible regardless of its superview’s bounds: https://zigz.ag/temp/SubviewBug/InterfaceBuilderXcode15.mov Is this a bug? Or did I miss something in macOS 14 Sonoma SDK release notes, which would indicate from now on this is expected behaviour (highly unlikely)? -- Dragan ___ 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
NSFileCoordinator woes
Hi all,
I’ve never used NSFileCoordinator class, simply because I haven’t had any need
for it until now. And now that I’m about to need it rather soon, I’m trying to
get a grasp on it, but it does’t go very well so far. Even though the
documentation reads pretty clear, I don’t seem to get it correctly. Also, I
haven’t found any example online, which would be of any value to me, so I’m
taking my chances here. In order to begin to understand it, I’ll start with the
simplest real case scenario, for which I don’t even understand yet whether
NSFileCoordinator is the way to go.
Let’s say, I have a bunch of directories in a parent directory (so, all are at
the same level in the file system hierarchy), which I want to compress and pack
in a ZIP archive (for example) programatically (e.g. using libarchive). After
selecting which directories to zip, I’d like to ensure that once the zipping
operation has started, any changes to all files and directories in the
hierarchies of selected directories to be packed will stay unchanged, until the
zipping operation is complete. That means, no file anywhere in the hierarchies
should be modified in any way and no directory or file anywhere in the
hierarchies should be added, deleted or moved.
I thought I would achieve this by using one NSFileCoordinator and a bunch
NSFileAccessIntent objects, each for every directory at the top level of the
hierarchies. The intents will be for reading without changing, because that’s
what I want to do; just to read those directories and files (and zip them)
without making any changes to them. The code would be something like this (I
want to do the operation asynchronously):
NSMutableArray *intents = [NSMutableArray arrayWithCapacity:[sources count]];
for (NSURL *source in sources)
[intents addObject:[NSFileAccessIntent readingIntentWithURL:source
options:NSFileCoordinatorReadingWithoutChanges]];
NSFileCoordinator *coordinator = [[NSFileCoordinator alloc]
initWithFilePresenter:nil];
[coordinator coordinateAccessWithIntents:intents queue:[NSOperationQueue new]
byAccessor:^(NSError *error)
{
// Do the zipping here.
}];
It looks simple and straightforward, but it doesn’t really work as I thought it
would. Once the operation is started, I can modify files and directories the
way I described above, from within the same application/process, as well as
others (using NSFileCoordinator approach), like Finder.
Hence, I’d really appreciate if someone can point me in the right direction.
For example, what needs to be done to achieve this simple example I described
above. Once I get some pointers, I may start understanding those classes and
documentation in the right way and work myself through more complex examples
and use cases.
Thanks,
-- Dragan
___
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
NSFileCoordinator operations on a directory (and it's content)
Since my question is about specific Cocoa API, but it also involves file system operations, I don't know it the appropriate place to ask is here or Filesystem-dev list, so I'll ask on both (and hope nobody will mind it :-)) I have an application, which "messes" with files in different ways. It can modify, move, copy, even delete them. So far all file operations were performed directly, without any checking if affected files were already busy or locked by other processes (or even the same application). So, in case a locked file is encountered and the operation failed, an appropriate error was reported. Now I want to enhance this behaviour and ensure two things: - make sure all files to be performed on are available for the operation in question (not busy/locked by other processes) - before the operation starts, inform other processes, so they can act accordingly if necessary. The most obvious solution to me is using NSFileCoordinator class and its reading/writing options. And even though documentation for this class is quite descriptive and helpful, I have some unanswered questions. So before doing my own tests (and perhaps even coming to potentially wrong conclusions), I'd like to ask here if someone has already had experience with this class and what I want to achieve with it. The basic question is: if I start coordinated operation (reading or writing) on a directory identified by an URL, does that operation intent automatically spans to all files and folders in the directory, all the way down the whole directory hierarchy? Or let me try to me more specific; I want to read all files in a certain directory, but then also list all its subfolders and read their (sub)files and go on like that down the directory hierarchy. While doing so, I don't want any other process to mess (modify, delete…) with any of those subfiles and subdirectories in the hierarchy. Is it enough to request coordinated reading to the root directory only, or do I still need to require coordinating reading to subfiles and subfolders? Or to put it another way, if I start coordinated reading on the root directory only, will other processes still be allowed to mess with subfiles and subdirectories? Or does this behaviour depend on the read/write option I actually want to perform? For example, requesting NSFileCoordinatorReadingWithoutChanges on a directory doesn't necessarily imply reading intent to all its subfolders and subfiles down the hierarchy. But requesting e.g. NSFileCoordinatorWritingForDeleting on a directory certainly implies the deletion will also affect all its subfiles and subfolders. I hope I was clear enough about what I want to achieve. Thanks for any insights. -- Dragan ___ 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
NSTableView dragging source image
Hi all, I have a simple problem, but I’m not able to solve it in an easy way, so I suspect I’m doing something wrong. I have a simple view-based NSTableView, which is a dragging source. The data being dragged are provided to the pasteboard using the standard data source method - [NSObject tableView:writeRowsWithIndexes:toPasteboard:]. When rows of the table view are dragged, AppKit automatically creates a dragging image consisting of the visual copy for all dragged rows and all columns of the table view. If I want only particular columns, I can override -[NSTableView dragImageForRowsWithIndexes:tableColumns:event:offset:] and include only the columns I want in the dragged image. Since [NSObject tableView:writeRowsWithIndexes:toPasteboard:] is rendered deprecated as of macOS 11, I want to use the alternative (which also supports multiple item dragging) -[NSObject tableView:pasteboardWriterForRow:]. However, when I use this method, AppKit creates a dragging image consisting of the visual copy for all dragged rows, BUT ONLY the column where the drag started. Overriding -[NSTableView dragImageForRowsWithIndexes:tableColumns:event:offset:] has no effect, as in this case that method isn’t being called at all. So the question is, how do I influence the dragging image creation in the latter case? I haven’t found in docs anything related to that (except for the method mentioned above, but not being called in this case). Implementing data source method -[NSObject tableView:updateDraggingItemsForDrag:] doesn’t help, as it’s really intended to change the dragging image after the dragging has started and at the time it’s called for the first time, the AppKit created image is already there and visible. Thanks a lot for any solution, hint or a suggestion. -- Dragan ___ 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: Set focus on NSTextField in an NSMenuItem
> On 20. 10. 2022., at 01:22, Sandor Szatmari wrote: > > I have a status item and in order to get it to show I have to call this in my > code that orders in the view/window > >[[NSApplication sharedApplication] activateIgnoringOtherApps:YES] > > I have no idea if this is the best way to accomplish this, but it works for > me… > On 21. 10. 2022., at 04:49, Richard Charles wrote: > > In a macOS document based application I added a menu item to a submenu and > set the view of the menu item to a NSTextField. This was done using Interface > Builder. It works just fine. Sandor, Richard… I know guys… Please read my latest reply in this thread and the explanation why I couldn’t set the focus on a text field inside a menu. -- Dragan ___ 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: Set focus on NSTextField in an NSMenuItem
> On 19. 10. 2022., at 03:52, Eric Schlegel wrote: > > > I can tell you that the Help menu does itself use makeFirstResponder: on the > text view… Eric, thanks for detailed explanation and willingness to help. Your message triggered me to play with the issue a bit more and I figured out what the problem is. But I also realised I’ve come to some wrong conclusions before, so I want to correct myself as well so that nobody here is left confused by them. I’ll do that first… > On 18. 10. 2022., at 18:43, Dragan Milić wrote: > > This issue isn’t related to the menu being attached to the NSStatusItem, it > also happens in the main and/or contextual menu within the application. I’d > eventually want to set the focus on the text field programmatically each time > the menu appears, but that’s not possible either. This was something I observed quite some time ago and I admin I haven’t confirmed it again before I sent my initial message here. God knows what I did wrong at that time, but I can say my above statement is completely false! Placing NSTextFiend inside NSMenuItem works fine in both main and contextual menus in the application. The text field gets focus when the menu opens, sending -[NSWindow makeFirstResponder:] is not even necessary. Now, my problem is that the application is defined as LSUIElement=YES (or its activation policy is programmatically set to NSApplicationActivationPolicyAccessory), meaning it doesn’t show its icon in the Dock, it doesn’t show its main menu, nor can it be made active with alt+tab. As known, clicking the status item of any application and making its status item menu visible, doesn’t really make the application active, and in my case that affect functionality of the text item. So, when I click on the status item and show the status item menu, the application is not really active and hence is text field (kind of) disabled, not being able to receive events. If I set application’s activation policy to NSApplicationActivationPolicyRegular and make it active (clicking on its icon in the Dock or alt+tabbing) before I click its status item, the status item menu appears with the text field active and focused, ready to be typed into. I haven’t find the complete solution yet. Sending -[NSApp activateIgnoringOtherApps:YES] does the job partially; clicking the status item and opening its menu results in the application being activated, but that automatically closes the menu immediately upon being open. But the application stays active, so clicking the status item again finally opens the menu with the text field active and having focus. If anyone have any idea how to solve this, I’d be thankful to hear it. -- Dragan ___ 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: Set focus on NSTextField in an NSMenuItem
> On 18. 10. 2022., at 19:11, Alex Zavatone wrote: > > I am speaking from an iOS perspective but, is there something like > makeFirstResponder? Yes, there is. It should be sent to an NSWindow instance and I tried to do that in -[NSMenuDelegate menuNeedsUpdate:], or -[NSMenuDelegate menuWillOpen:] (in both cases after some delay, as the window of the text field is still set at the time those delegate messages are received) and I also subclassed NSTextView and tried to call -[[self window] makeFirstResponder:self] in overridden -[NSView viewDidMoveToWindow] method, but those calls have no effect. Even if it worked, it’d still be a problem setting the focus on the text field by clicking on it. -- Dragan ___ 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
Set focus on NSTextField in an NSMenuItem
Hi all, I’m developing a tiny application, which has an NSStatusItem instance with a menu. One for the menu items of the menu has a custom view, which is either an NSTextField instance, or in can even be an NSView instance containing the NSTextField instance (the latter approach enables me to add some borders around the text field). However, I have problems setting focus on that text field. Clicking the text field does nothing and if I click on it repeatedly a couple of times, the application hangs (and eventually crashes), getting into the infinite loop of -[NSMenuWindowManagerWindow setFirstResponder:] messages, even stealing keyboard events from all other applications while hanging! In essence, I can’t set focus on the text field nor type anything into it. I had this problem on older versions of macOS (Catalina and older), but after clicking on the text field a couple of times, it would get the focus eventually. On Big Sur and later, it’s not possible, and clicking on the text field repeatedly hangs and crashes the application. This issue isn’t related to the menu being attached to the NSStatusItem, it also happens in the main and/or contextual menu within the application. I’d eventually want to set the focus on the text field programmatically each time the menu appears (so a user can start typing immediately, something like Spotlight used to do in the older versions of macOS), but that’s not possible either. The only similar attempt I could find is dated back in 2008 on this very list, you can find it here: https://lists.apple.com/archives/cocoa-dev/2008/Jan/msg00138.html But even at that time, the problem was hard to solve. I know NSMenu has its own track of the event loop and I assume that’s what causes the problem. Action-On-Click oriented controls (NSButton, NSPopUpButton…) work fine embedded in an NSMenuItem instance, but not NSTextField. I wonder if what I want to achieve is even possible. If so, I’d really appreciate if someone can offer the solution or point me in the right direction for further investigation and solution attempts. Cheers, -- Dragan ___ 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: Incompatible CoreData version crash
> On 4 Aug 2021, at 12:30, RhapSoft Feedback wrote: > > Hi Dragan, > > I experienced a similar crash with my Mac app recently when using recent > versions of Xcode. > I found a way to fix it: > I added the CoreData framework explicitly in the target dependency setting as > it was not present. > I hope it will also fix it in your case. Romain, that actually did the trick!! Thank you so much -- Dragan ___ 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
Incompatible CoreData version crash
Not really Cocoa but more Xcode/SDK problem, but still… I’ve got a Mac application, which uses CoreData. The usage of the framework is rather moderate, nothing really fancy about it. The application is build with SDK 11 (1Big Sur), but the minimal deployment target is Sierra (10.12). The last “successful” build was made using Xcode 12.4 (12D4e) and it used SDK version 11.1. After I updated Xcode to the latest version 12.5.1 (12E507) it apparently updated SDK version to 11.3 and I started getting problems dynamically linking to CoreData version on older versions of macOS. The application works okay on Mojave and later, but on High Sierra and earlier it crashes on launch with the following error: Dyld Error Message: Library not loaded: /System/Library/Frameworks/CoreData.framework/CoreData Referenced from: /Applications/MyApp Reason: Incompatible library version: MyApp requires version 300.0.0 or later, but CoreData provides version 1.0.0 Now, the interesting thing is that I’ve got yet another macOS app, which also uses CoreData in a very similar fashion like the first one. It’s also built with Xcode 12.5.1 / SDK 11.3 and it runs fine on everything from Sierra to Monterey. The only difference related to CoreData usage is that the first one (the crashing one) uses options NSMigratePersistentStoresAutomaticallyOption: YES and NSInferMappingModelAutomaticallyOption: YES when creating persistent store, while the second application (the running one) doesn’t use any option. But I don’t think that actually matters in this case. Can anybody advise me how to solve this problem? Thanks! -- Dragan ___ 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: "nw_endpoint_handler_set_adaptive…" coming from XPC service
On 27 May 2021, at 20:48, Jens Alfke wrote: >> On May 27, 2021, at 11:17 AM, Dragan Milić via Cocoa-dev >> wrote: >> >> I’ve got an application, which uses (a couple of) XPC service(s) to >> accomplish various tasks. Since recently, I don’t know when exactly but >> probably after some macOS update, I started seeing these messages coming out >> when XPC services are used: >> >> [connection] nw_endpoint_handler_set_adaptive_read_handler [C1.1 >> 140.82.121.6:443 ready socket-flow (satisfied (Path is satisfied), viable, >> interface: en1, ipv4, dns)] unregister notification for read_timeout failed > > If your app works and isn't getting errors back through the API, then this is > probably just some internal logging used by Apple. There's a lot of that > stuff. It can be annoying to have it interspersed in your own logs, but I > don't think there's anything you can do about it. Yeah, I assumed that as well, but since it's started happening recently and it annoys me, I thought there may be something I can do. Ah well… -- Dragan ___ 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
"nw_endpoint_handler_set_adaptive…" coming from XPC service
Hi all, I’ve got an application, which uses (a couple of) XPC service(s) to accomplish various tasks. Since recently, I don’t know when exactly but probably after some macOS update, I started seeing these messages coming out when XPC services are used: [connection] nw_endpoint_handler_set_adaptive_read_handler [C1.1 140.82.121.6:443 ready socket-flow (satisfied (Path is satisfied), viable, interface: en1, ipv4, dns)] unregister notification for read_timeout failed or [connection] nw_endpoint_handler_set_adaptive_write_handler [C1.1 140.82.121.6:443 ready socket-flow (satisfied (Path is satisfied), viable, interface: en1, ipv4, dns)] unregister notification for write_timeout failed This happens when the service want’s to use outgoing connection. Not that it only happens in Xcode during debugging, but the deployment version of the application/XPC emits these messages to the console as well. However, everything works correctly as it has before. I’d like to surpass those messages going into the console, but I’d also like to understand what they actually mean and why they appear in the first place. Searching the Internet didn’t really revealed any useful info, so I hope someone here can help me. Anyone else seeing those? -- Dragan ___ 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
Accessing "iCloud" keychain using Keychain Services
Reading Keychain Services docs on and on and I can’t seem to find a way to access the keychain, which in Keychain Access application appears as “iCloud”. I’ve got no idea what its path could be so I could use SecKeychainOpen(), it isn’t in the default list returned by SecKeychainCopySearchList(), I can’t get it using SecKeychainCopyDefault(), even though it’s listed as “Default Keychains” in the Keychain Access,… I assume I should be looking completely elsewhere, but I’d appreciate any hint where that could be. Thanks, -- Dragan ___ 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: NSScrollView's custom content inset
> čet 05.11.2020., at 20:57, Rob Petrovec wrote: > > Check out NSTableViewStylePlain Yes Rob, that was it, thanks a lot!! And now I feel quite stupid, trying all complicated things (described in my second message), while it’s so very simple :-) To my defence, that value stands somehow apart, both in documentation and in IB, so it looked like some deprecated value to me. Additionally, I was paying attention to that page I posted (changes in macOS 11.0), where it says the padding is present regardless of the tableView style, so I never checked that value. Thanks again!! -- Dragan ___ 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
NSScrollView's custom content inset
… trying again, as the stupid DTK machine suddenly reseted itself (it does that regularly) and incomplete message was somehow sent on booting back!! What would be the best approach to set custom insets of the contentView (NSClipView) of a NSScrollView? I’ll try to describe the problem in more details… I’m trying to make and application look nice on upcoming Big Sur. The fact that Apple has made it so hard for an application (with reasonably complicated UI) to look good on both Bit Sur and older OS version is a topic for some other rant thread… Anyway, I’m trying to get rid of some unwanted NSTableView/NSOutlineView properties, introduced in Bit Sur. I’ve got a NSOutlineView with a single column. Cells (NSView based) in that single column show some custom content, mostly custom view full of custom Core Text drawing and colouring. It’s very important (visually appealing) if that custom content is stretched through the whole width of the table, practically to the edge of the window. This is how it should like (and does on Catalina and earlier)… https://zigz.ag/temp/10_15.png Big Sur introduces a lot of new NSTableView’s properties (which, in my opinion, just waste screen space), more about it here: https://developer.apple.com/design/human-interface-guidelines/macos/overview/whats-new-in-macos Besides increased default intercell spacing, inset and so on, there’s 6px (not customisable) padding at leading and trailing row edges. So even setting tableView style to NSTableViewStyleFullWidth, paddings remain. The final result of how the same portion of application's window looks on Big Sur is… https://zigz.ag/temp/11_0.png I want to avoid that padding on both sides and I don’t see any other way than to inset enclosing scrollView’s content view by 6px on left and right edges. automaticallyAdjustsContentInsets and contentInsets properties serve completely different purpose and besides, the docs say "The contentView is placed underneath these sibling views (scrollers, rulers…) and is only inset by the scroll view border and non-overlay scrollers”. So those properties don’t affect contentView (NSClipView) at all. So the question is, is there some reasonably easy and sensible way of doing the above? I want to mention in similar situations before I used to “hijack” the enclosing scrollView, put the outlineView (possibly with other views I needed) in a new custom view and then make that custom view a documentView of the scrollView. Unfortunately that approach seems invalid on Big Sur, as the outliveView seems to have gotten much more “under the hood” interactions with the enclosing clipView and scrollView and if I try that approach, outliveView’s frame and height get completely broken. The behaviour is especially weird if floating group rows are present. I tried this with both constraints and sprints & struts, and neither approach worked. Thanks in advance, -- Dragan ___ 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
NSScrollView's custom content inset
Hi all, What would be the best approach to set custom insets of the contentView (NSClipView) of a NSScrollView? I’ll try to describe the problem in more details… I’m trying to make and application look nice on upcoming Big Sur. The fact that Apple has made it so hard for an application (with reasonably complicated UI) to look good on both Bit Sur and older OS version is a topic for some other rant thread… Anyway, I’m trying to get rid of some unwanted NSTableView properties, introduced in Bit Sur. I’ve got a NSTableView with a single column. Cells (NSView based) in that single column show some custom content, mostly custom view full of custom Core Text drawing and colouring. It’s very important (visually appealing) if that custom content is stretched through the whole width of the table -- Dragan ___ 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
Creating OpenSSH compatible key pairs
Hello,
My question is not strictly related to Cocoa and I apologise for that, but this
place seems to be the only useful resource for macOS related development and
looking for information and questions (apart from noisy stack overflow).
Secondly, I’m not very experienced in cryptography and related topics, so it
may be possible I’m overlooking something quite obvious.
The straightforward question is: is it possible to create OpenSSH compatible
key pairs, like ssh-keyget utility does, using Security framework? Let’s say, I
want to do the equivalent of the following terminal command:
ssh-keygen -t rsa -b 4096 -C “m...@mail.com"
I’m trying that with this simplified piece of code:
CFMutableDictionaryRef privAttrs =
CFDictionaryCreateMutable(kCFAllocatorDefault, 0,
&kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
CFDictionarySetValue(privAttrs, kSecAttrIsPermanent, kCFBooleanFalse);
CFDictionarySetValue(privAttrs, kSecAttrLabel, CFSTR("m...@mail.com"));
CFMutableDictionaryRef attrs = CFDictionaryCreateMutable(kCFAllocatorDefault,
0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
CFDictionarySetValue(attrs, kSecAttrKeyType, kSecAttrKeyTypeRSA);
CFDictionarySetValue(attrs, kSecAttrKeySizeInBits, CFSTR("4096"));
CFDictionarySetValue(attrs, kSecPrivateKeyAttrs, privAttrs);
CFErrorRef error = NULL;
SecKeyRef privateKey = SecKeyCreateRandomKey(attrs, &error);
if (privateKey)
{
CFDataRef data = NULL;
OSStatus status = SecItemExport(privateKey, kSecFormatSSH,
kSecItemPemArmour, NULL, &data);
if (status == errSecSuccess)
{
// ... save private key data to a file ...
}
SecKeyRef publicKey = SecKeyCopyPublicKey(privateKey);
if (publicKey)
{
status = SecItemExport(publicKey, kSecFormatSSH, kSecItemPemArmour,
NULL, &data);
if (status == errSecSuccess)
{
// ... save public key data to a file ...
}
CFRelease(publicKey);
}
CFRelease(privateKey);
}
CFRelease(privAttrs);
CFRelease(attrs);
This seems to create valid RSA key pair, which I can add to the Keychain on
creation if I choose to (setting permanent attribute to true), but the
exporting operation doesn’t end up with files I expect. The PEM armour seems
not to be correct, the text representation of the key begins and ends with
-BEGIN/END RSA PRIVATE KEY- as opposed to -BEGIN/END OPENSSH
PRIVATE KEY- and the key structure looks different in general. If I try to
show key fingerprint using
ssh-keygen -l -f
I get response that “ is not a key file. If I, for example, try to
upload the public key to GitHub to use for SSH connection, it’s rejected,
because “key is invalid, you must supply a key in OpenSSH public key format."
I’d appreciate if anyone points out what I’m doing wrong and whether this is
achievable with Security framework at all.
Thanks,
-- Dragan
___
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: Future of Cocoa
> čet 21.11.2019., at 23.43, Pascal Bourguignon wrote: > > It’s not like children not being happy. That comment was related to “I’m leaving this place” announcement, probably because “most of you don’t agree with what I find ‘valid concerns’ so I’m leaving”. That’s exactly how it sounded to me. > The Apple ecosystem implies an extraordinary maintenance load. > Specifically, your application must provide enough revenue to pay for a > couple of developpers only to track the changes Apple makes to the API, and > update it on each new version of the system (which occur about yearly). > So, count about 100,000 €/year to 200,000 €/year. > If your application doesn’t provide this profit, then you cannot follow, and > it will quickly be dropped from the the AppStore. > > Are only applications providing good revenue worth developing and worth > having? > Why couldn’t we have application developed once for a few users, and working > consistently over long periods, on a stable platform? > Currently the only solution would be to package such application in frozen > hardware and system software, which is not practical (users would need > different computers for each application!), and feasible (computers are not > really buillt to last more than a few year of usage). > > Actually, things have changed. On Macintosh, basically an application > developed in 1984 against the Inside Macintosh (1.0) specifications still > worked in 1999 in the blue box with MacOS 9.1. The platform was more stable. > > So what can we do? I agree with all your points. It’s not easy, i’ve never said it was. But that’s the matter of the fact ever since 2001. I know applications made for mac in 1984 would still work in 1999. I know Win application made in 1995 would still work in 2019 (with minor or no changes at all). Would I like it to be the same for the modern macOS platform? I sure would! But it’s not like that and it hasn’t been ever since Mac OS X was officially released in 2001. It’s almost 18 years now, that’s longer time span than 1984 - 99 and if anyone was working in Mac environment for that long, one should get used to it already. There’s a positive side of it (Apple pushing new technologies) and a negative side (constant updating of your software, so that it just runs normally on each new major OS update). I don’t like it too, and often hate it, especially when some frameworks are deprecated (and later removed) without valid replacement, just because Apple guys think “you don’t need it and hence should not use it” (like LSSharedFileListItemRef and related API, for example). But even then, those deprecations, no matter how silent (not announced at WWDC keynote/platforms-state-of-the-union) are mentioned in developer's release notes. And only removed after a couple of next OS updates. Do you really consider seriously developing for a certain platform without even reading major OS update developer's release notes? And then we come to those HUGE deprecations, such are Carbon, 32-bit and OpenGL, which were loudly announced in both Keynotes and platforms-state-of-the-union videos, particular developer sessions and on MANY places outside of WWDC, in all relevant Mac (and not only Mac, but IT and software dev in general related) web sites, documentation etc… And after years and years of getting deprecation warnings, and OS warning you about 32-bit apps on launch and what not, when all those are finally removed, people, who claim to be developers for the platform, find themselves surprised?! Sorry, call me stubborn, or dickhead, or whatever, but I just can’t take those people seriously. And then, other people use this list for what it really is meant for, they start posting links and advices to those who has been left behind, to help them to update their apps to the current APIs, and in return they get more complains and whining about the situation? I mean, following the current thread, Objective-C (and after introduction of SwiftUI, probably AppKit/UIKit) will be declared deprecated in, say 7 - 8 years (just a wild guess, don’t take it seriously), and some people will ignore it and keep their apps tied to those APIs and technologies and when ObjC/AppKit/UIKit are finally removed in, like, 15 - 16 years, they will probably find themselves surprised (again). -- Dragan ___ 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: Future of Cocoa
> čet 21.11.2019., at 23.06, Matthew Kozak wrote: > > Wow. > Debate (even heated) about Cocoa-dev (broadly) is one thing, but the personal > attacks, and attack on the list itself to the point of rage quitting, are all > unnecessary. Before sending messages, please look in the mirror and say them > out loud to an actual human face and then think about it for a moment from > the other perspective. It'll do a world of good and some good for the world. No problem here to say it out loud to my own face, or anyone’s else. The subject has been beaten to death, in the list where it doesn’t really belong (not just my opinion), over and over again. People are surprised by deprecation of OpenGL? Really? People are surprised by deprecation of Carbon? REALLY? If, for example, I develop for Windows, I would make damn sure I’m up to date with all ongoing development and changes about the platform, because that’s my job, that’s the nature of the job (things constantly changing) and if I’m not happy about that I better be sure to try to do something else! And here people complain for weeks already about deprecations, which were announced YEARS ago, in Carbon case almost a DECADE ago. And they keep whining, like anything’s going to change? And then that famous “I leave” announcement, like children not being happy with how others play with them, so grabbing their toys and leave… But not before making a verbal announcement about it… Well yes, good bye! What else is to say? No personal or list attacks whatsoever. You’re welcome -- Dragan ___ 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: Future of Cocoa
> ćet 21.11.2019., at 21.20, Pier Bover wrote: > > It's time for me to leave this mailing list. Yeah! Good bye! ___ 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: Thoughts on Cocoa
> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote: > > It wasn’t clear to us (outside Apple) that Carbon was a temporary API until > 2007, when Apple suddenly abandoned 64-bit Carbon. I don’t agree. The first version of macOS predecessor (Rhapsody) shipped only with “Yellow Box” (which became “Cocoa”) API . The first version of “Blue Box” (which became “Carbon”) API was introduced a bit later, with specific note it’s a transitional API, being there to make existing MacOS (8/9) applications run on Rhapsody without, or with small, modifications. And that was introduced only after Apple realised developers aren’t ready to jump on “Yellow Box” just like that, no matter how great (for the time) it was. Apple also strongly and clearly advised all new development should be done in Yellow Box/Cocoa. Sure it took Apple too quite some time to transition everything away from Carbon, but it was clear from the beginning that Carbon was there just as long as it was really needed, and not a minute longer. With every early major releases (until 2007) of macOS, Apple put strong emphasis in release notes which OS-bundled applications have gone from Carbon to Cocoa. -- Dragan ___ 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: Thoughts on Cocoa
> čet 03.10.2019., at 10.53, Matthew Kozak via Cocoa-dev wrote: > > Well, actually: > http://www.eat-more-burgers.com/blog/drugstore-burger > (couldn't resist). > > Maybe more like going to a drug's manufacturing plant to complain about your > PBM (pharmacy benefits manager), but yeah. Touché! -- Dragan ___ 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: Thoughts on Cocoa
> čet 03.10.2019., at 00.49, John Randolph via Cocoa-dev wrote: > > Speaking as a former moderator of this list, this thread is off-topic for > Cocoa-dev. This list is for TECHNICAL discussion and help. > Kindly take it to reddit or wherever else the denizens of > comp.sys.mac.advocacy ended up. This whining crap seem to be appearing on the list every now and then, with mostly the same participants. While I may or may not agree with some or all of your points, This is not the place for that! Do you regularly go to the pharmacy and ask for double cheese burger in there? -- Dragan ___ 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: Hide badge of NSDraggingSession
> pet 26.07.2019., at 03.08, Rob Petrovec wrote: > > I would not recommend using those deprecated API. They are not long for this > world. With that said, I don’t have a better solution. Yeah, I’d like ti avoid using that too. > pet 26.07.2019., at 03.30, Steve Mills via Cocoa-dev wrote: > > Yeah, hard to say how much longer they'll be available. You could always add > a single item using a custom NSPasteboardWriting class and supply your own > image. It would hold the multiple items and write them. The thing is, in that dragging session I have to supply a list of URLs, so that other applications expecting URLs (like Finder, for example) would accept them. As a matter of fact, speaking about specifics, what I really want is to do is drag a couple of URLs into System Preferences’ “Full Disk Access” list, and that one accepts only lists of URLs, as far as I know. Now, I want it to look like a user is only dragging an icon of my application (which he/she really does), but application’s privileged helper needs to be added into “Full Disk Access” too. I don’t want user to see that (and potentially get confused), so my intention is to show just application’s icon during the drag. That works okay (the second dragging items has no content), but since I actually have two dragging items, the count badge appears, and that doesn’t look very nice. Speaking of above mentioned deprecated method, I tried to use it and write URLs to the dragging pasteboard using -[NSPasteboard writeObjects:]. That worked well and looked exactly as I wanted on Mojave, but on Catalina it throws exception for “there are two dragging items but only one dragging image, there should be one image per item”. Finally, I know of application which does exactly the same as I described and want. The session contained three dragging items, but the badge was hidden. So I thought there could be something obvious I may be missing. Now it seems to me that only can be done through private API calls and/ore other hackery. Cheers, -- Dragan ___ 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: Hide badge of NSDraggingSession
> On pet 26.10.2019,. at 02.37, Steve Mills via Cocoa-dev wrote: > > Use the single image methods instead of adding multiple items. Do you think of deprecated (as of Lion) one: -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] ?? -- Dragan ___ 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
Hide badge of NSDraggingSession
Hi everyone, Here's a very straightforward question: starting a dragging session with -[NSDraggingSession beginDraggingSessionWithItems:event:source:] and having multiple dragging items automatically adds a badge, showing items count, to the composited dragging image. Is there any public way to hide/not show that badge? For certain reasons, even though a user can drag multiple items of certain type in my application, I want just a simple image without a badge displayed. I may be missing something obvious in the documentation and if so, please provide a reference where I can find it. Thanks in advance -- Dragan ___ 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
