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,
, );
CFDictionarySetValue(privAttrs, kSecAttrIsPermanent, kCFBooleanFalse);
CFDictionarySetValue(privAttrs, kSecAttrLabel, CFSTR("m...@mail.com"));
CFMutableDictionaryRef attrs = CFDictionaryCreateMutable(kCFAllocatorDefault,
0, , );
CFDictionarySetValue(attrs, kSecAttrKeyType, kSecAttrKeyTypeRSA);
CFDictionarySetValue(attrs, kSecAttrKeySizeInBits, CFSTR("4096"));
CFDictionarySetValue(attrs, kSecPrivateKeyAttrs, privAttrs);
CFErrorRef error = NULL;
SecKeyRef privateKey = SecKeyCreateRandomKey(attrs, );
if (privateKey)
{
CFDataRef data = NULL;
OSStatus status = SecItemExport(privateKey, kSecFormatSSH,
kSecItemPemArmour, NULL, );
if (status == errSecSuccess)
{
// ... save private key data to a file ...
}
SecKeyRef publicKey = SecKeyCopyPublicKey(privateKey);
if (publicKey)
{
status = SecItemExport(publicKey, kSecFormatSSH, kSecItemPemArmour,
NULL, );
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
Re: Size of compiled NIBs in Xcode 9 (10.13 SDK)
On Jan 24, 2018, at 20.56, Jeremy Hughes wrote: > Vince has explained why it does matter. > > If you change the deployment target to 10.13 (which you probably don’t want > to do) the application icons should no longer be duplicated. They’re > currently being duplicated for backwards compatibility with old systems. I'm not talking about icons and assets, I'm talking about compiled NIBs, please read my initial message again. Changing to 10.13 as the deployment target changes nothing in my case, compiled NIBs are still considerably bigger than those compiled with Xcode 8 (and its embedded ibtool and 10.12 SDK). -- 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: Size of compiled NIBs in Xcode 9 (10.13 SDK)
On Jan 24, 2018, at 20.03, Jeremy Hughes wrote:
> I posted a related question in https://apple-dev.groups.io/g/xcode/
> ("Assets.car is much larger for High Sierra builds”) but I didn’t get much in
> the way of a reply.
Yeah, my problem is not exactly related. But thanks for the link, I didn't know
about that group, I'll post the question there as well.
I mean, it's not really a big deal, but I'd like to know why it happens. I've
got a small neat application I'm just about to release (one week from now) and
when I decided to build it agains 10.13 SDK (anyway, I don't think it's SDK
related, it probably has to do something with ibtool) in Xcode 9, it went from
6.61 MB to 6.98 MB, just due to differences in NIBs files sizes. Still not a
big deal, but 5.6% increase in size of a bundle due to NIBs?! BTW, in both
cases (Xcode 9 - 10.13 SDK and Xcode 8 - 10.12 SDK) the deployment target is
macOS 10.11, so I don't think that setting matters.
-- 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
Size of compiled NIBs in Xcode 9 (10.13 SDK)
My question is Xcode/ibtool related and not Cocoa, but since Xcode-users list is decommissioned quite some time ago, and related subtopic in Apple Dev Forum isn't very active, I hope you won't mind me asking here, since I couldn't fine explanation anywhere else. I've finally upgraded to macOS 10.13 and Xcode 9 and ever since that happened, I've noticed the sizes of compiled NIBs being considerably bigger than what it was when compiling with Xcode 8 on macOS 10.12 (10.12 SDK). That difference can sometimes come close to 95% ! For example, I've got a (pretty packed) NIB, which compiles with Xcode 8 and 10.12 SDK into a compiled file of 51 KB. The same file compiles with Xcode 9 and 10.13 SDK into a compiled file of 95 KB! What is the reason for this. I compiled projects in terminal and in the "CompileXIB" step I see ibtool called with pretty standard set of options, nothing fancy there. Currently I don't have any machine with macOS 10.12 and Xcode 8 installed to compare what were the options passed to ibtool there, but whatever they were, I wouldn't expect this kind of difference. Can someone enlighten me here please? 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: Exception in IKImageBrowserView in macOS 10.13 GM
On sre 20.09.2017., at 15.26, Steve Mills wrote: > It is, sadly, deprecated, you know. NSCollectionView is a laughable > replacement. My apps using IKImageBrowserView started autoscrolling to the > bottom starting in 10.12, IIRC. Trying to replace them with NSCollectionView > was so maddening and fraught with unfinished or non-Apple-like "features" > that I started looking at 3rd party replacements. For all the great stuff > that Apple does, they sure pull some mighty boners often. Deprecated in 10.13? I haven't read 10.13 dev documentation yet (I suppose I should have) and the current document says it will be deprecated in the future, but not specifying when. Anyhow, knowing Apple that certainly means they won't bother with my bug report abut this issue at all :-( -- 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
Exception in IKImageBrowserView in macOS 10.13 GM
I've got a fairly simply application, with IKImageBrowserView embedded in
NSScrollView, as is the most common case. When running on macOS 10.13 High
Sierra GM and whenever the IKImageBrowserView is presented and there are enough
items in it to make it scrollable, it throws and exception with the following
stack trace:
NSInvalidArgumentException
*** -[NSProxy doesNotRecognizeSelector:lastIndex] called!
0x7fff59b71b27 0x7fff7e452c76 0x7fff57c65bfd 0x7fff57b4a510 0x7fff57b49ed8
0x7fff62254b98 0x7fff62288543 0x7fff6226b819 0x7fff59bc66d8 0x7fff7f2cb6c1
0x7fff7f2cb56d 0x7fff7f2cac5d
NSExceptionHandlerExceptionRaiser (in ExceptionHandling) + 160
objc_exception_throw (in libobjc.A.dylib) + 48
+[NSException raise:format:] (in CoreFoundation) + 205
___forwarding___ (in CoreFoundation) + 1456
_CF_forwarding_prep_0 (in CoreFoundation) + 120
IKLimitIndexSetToCount (in ImageKit) + 51
-[IKImageBrowserView(ImageBrowserImport) startScrollPrefetchTask] (in ImageKit)
+ 157
-[IKTaskManager taskLoop] (in ImageKit) + 2389
__NSThread__start__ (in Foundation) + 1197
_pthread_body (in libsystem_pthread.dylib) + 340
_pthread_body (in libsystem_pthread.dylib) + 0
thread_start (in libsystem_pthread.dylib) + 13
There's really nothing special in the implementation. IKImageBrowserDataSource
mrotocol methods looks something like:
- (NSUInteger)numberOfItemsInImageBrowser:(IKImageBrowserView *)aBrowser
{
return [myItems count];
}
- (id)imageBrowser:(IKImageBrowserView *)aBrowser
itemAtIndex:(NSUInteger)anIndex
{
return myItems[anIndex];
}
and items implement IKImageBrowserItem also in a very simple way:
- (NSString *)imageUID
{
return [self bundleIdentifier];
}
- (NSString *)imageRepresentationType
{
return IKImageBrowserNSImageRepresentationType;
}
- (id)imageRepresentation
{
return [self image];
}
- (NSString *)imageTitle
{
return [self displayName];
}
- (BOOL)isSelectable
{
return YES;
}
- (NSImage *)image
{
if (!_image)
{
NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize(128.0,
128.0)];
[image lockFocus];
NSRect imageRect = NSMakeRect(.0, .0, 128.0, 128.0);
[[NSColor redColor] set];
[NSBezierPath fillRect:imageRect];
[[NSColor blackColor] set];
[NSBezierPath strokeRect:imageRect];
[image unlockFocus];
[self setImage:image];
}
return _image;
}
The UI is implemented using xib file, not a storyboard. Even Apple's official
sample code available at
https://developer.apple.com/library/content/samplecode/ImageBrowserViewAppearance/Introduction/Intro.html
suffers from the same issue.
Have anyone find a workaround for this issue. It looks like a bug in the SDK.
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: Creating "Application Scripts" subfolder in sandboxed environment
Though it's definitely not an ideal solution, manually removing the container corresponding to the application's bundle identifier in "~/Library/Containers", and then relaunching the application causes the corresponding Application Scripts subfolder to get created. Thinking more about it, I realise the API for creating the subfolder would probably not be consistent, especially since the application is granted just read-only access to the scripts subfolder, but it would really be useful if the subfolder is created (if it doesn't exist) the next time the application launches regardless of whether corresponding container folder exists or not. For now I can only hope users won't manually mess with folders "hidden" inside "~/Library", so this won't be a big issue. If the fourth parameter is "NO", only the plain file-path URL is returned, which can't be revealed (as the subfolder doesn't exist) and the application does nothing as a result of user action. Therefore I will set the fourth parameter to "YES". That way, users will be presented with an error at least, and if they report it I'll know what the issue is and how to fix 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: Creating "Application Scripts" subfolder in sandboxed environment
On pet 09.06.2017., at 14.59, Shane Stanley wrote:
> You will get that error if your app isn't correctly code-signed.
I tried with three signing identities (“Mac Development”, “3rd Party Mac
Developer Application” and “Developer ID Application”) and all three behave the
same. The application also does a lot of other things in accordance with
sandboxing rules/limitations and there weren’t any problems with operations
“not being permitted”. Executing "codesign --verify —verbose=4 —deep” and
"spctl -a -t execute -v” gives expected results ("valid on disk: satisfies its
Designated Requirement” and “accepted: source=Developer ID”), so I don’t think
the issue is related to code signing. I might be wrong though.
> Your app can't do that -- scripts can only be installed in that folder by the
> user.
I know that. What I meant by “installing" is getting scripts subfolder
(creating it if necessary), reveal it in Finder using NSWorkspace’s -openURL:
and ask user to drag particular icon (representing bundled script file) from
the application UI into revealed folder in Finder (the application has
"com.apple.security.files.user-selected.read-write” entitlement defined). It
all works fine if the scripts subfolder exists, it fails if the subfolder
doesn’t exist and I try to create 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
Creating "Application Scripts" subfolder in sandboxed environment
I'm developing a sandboxed application, which should run some scripts and
following sandboxing rules, those should be located in "~/Library/Application
Scripts/com.mydomain.myapp". The application also tries to be friendly to users
and offers them to "install" predefined scripts (bundled in the application
package) into that folder. To gain access to the application script folder, I
use standard method of the NSFileManager, so the code looks something like:
NSError *error;
NSURL *scriptsFolder = [[NSFileManager defaultManager]
URLForDirectory:NSApplicationScriptsDirectory inDomain:NSUserDomainMask
appropriateForURL:nil create:YES error:]
This works fine if the scripts subfolder already exists. However, it if
doesn't, the application can't create it. If I pass "NO" as fourth parameter I
get back the url, but it's useless (it contains only the path), since the
folder is nonexistent. If I pass "YES" as fourth parameter, so that the folder
is created if necessary, I get the following error:
Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the
file “com.mydomain.myapp” in the folder “Application Scripts”.” UserInfo
{NSFilePath=/Users/milke/Library/Application Scripts/com.mydomain.myapp,
NSUnderlyingError=0x608000259bf0 {Error Domain=NSPOSIXErrorDomain Code=1
"Operation not permitted"}}
Is there any way to create "com.mydomain.myapp" subfolder inside "Application
Scripts" folder without defining temporary exception entitlement or explicitly
prompting user to create it him/herself? If not, should this be considered a
bug?
On a related note, when I started implementing and testing this feature, the
folder "com.mydomain.myapp" was already in the "Application Scripts". When do
those applications specific script subfolders get created and by which process?
Once I've deleted it I can't seem to make the system to create it again.
Thanks for any info.
-- 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
Cocoa UI preservation - simple example
I’m trying to make usage of Cocoa UI preservation API, but it seems I got stuck
at the very beginning and even after almost two hours of trying to figure out
what I’m doing wrong, there’s no progress at all. I’m sensing I’m missing
something obvious, but I don’t know what that would be.
Anyhow, I’ve created a very simple single window application, with (main)
window, controlled by its accompanying (main) window controller. The
controller implementation is fairly simple:
@implementation MainWindowController
- (instancetype)init
{
self = [super initWithWindowNibName:@"MainWindow" owner:self];
if (self)
{
// Some code here.
}
return self;
}
- (void)windowDidLoad
{
[super windowDidLoad];
// Some code here.
}
@end
The application delegate is responsible for preservation and it’s implemented
exactly like in many examples I’ve found online, as well as in Apple
documentation:
@interface AppDelegate ()
@property (nonatomic, strong) NSWindowController *mainWindowController;
@end
@implementation AppDelegate
+ (void)restoreWindowWithIdentifier:(NSString *)anIdentifier
state:(NSCoder *)aState
completionHandler:(void (^)(NSWindow *, NSError
*))aCompletionHandler
{
NSWindow *window;
if ([anIdentifier isEqualToString:@"main window"])
{
AppDelegate *delegate = [NSApp delegate];
window = [[delegate mainWindowController] window];
}
aCompletionHandler(window, nil);
}
- (NSWindowController *)mainWindowController
{
if (!_mainWindowController)
{
_mainWindowController = [[MainWindowController alloc] init];
[[_mainWindowController window] setRestorable:YES];
[[_mainWindowController window] setIdentifier:@"main window"];
[[_mainWindowController window] setRestorationClass:[self class]];
}
return _mainWindowController;
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
[[self mainWindowController] showWindow:self];
}
- (void)applicationWillTerminate:(NSNotification *)aNotification
{
}
@end
The window itself (loaded from the nib file “MainWindow.xib” contains just one
tab view, with four tabs.
When I start the application, the window appears just like it was designed in
the nib file. Then I resize it and change its position on the screen, as well
as change selected tab of the tab view. Quitting and relaunching the
application shows the window just like it was designed in the nib files, not UI
changes were preserved. Themethod never gets executed. Additionally, I
don’t see any preserved data for the application being saved in the
“~/Library/Saved Application State/” folder.
Is the code above enough to make this simple UI preservation work, or do I need
to do something more (and what)?
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
Re: NSSplitViewController and loading of NSSplitViewItems
On sre 09.03.2016., at 01.49, Dragan Milić wrote: > As it becomes common for my recent posts, since the issue is not easy to > explain in words, I’ve attached a very simple project demonstrating it. > > It’s ongoing troubles with NSSplitViews, this time specifically with > NSSplitViewController. A sentence from documentation says: > > “A split view controller employs lazy loading of its views. For example, > adding a collapsed split view item as a new child does not load the > associated view until it is revealed.” > > I can get this to work (in both code and IB) only when setting an instance of > NSSplitViewController as a contentViewController of a window. But I can’t get > NSSplitViewController to load NSSplitViewItems otherwise. Okay, I’ve just figured it out. It’s rather simple, but kind of stupid. The problem is that the “”inner” split view controller wasn’t being loaded at all. In order to load it, one has to access not its “splitView” property, but its (from NSViewController superclass inherited) “view” property which is not very useful in case of split view controller. -- 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
NSSplitViewController and loading of NSSplitViewItems
As it becomes common for my recent posts, since the issue is not easy to
explain in words, I’ve attached a very simple project demonstrating it.
It’s ongoing troubles with NSSplitViews, this time specifically with
NSSplitViewController. A sentence from documentation says:
“A split view controller employs lazy loading of its views. For example, adding
a collapsed split view item as a new child does not load the associated view
until it is revealed.”
I can get this to work (in both code and IB) only when setting an instance of
NSSplitViewController as a contentViewController of a window. But I can’t get
NSSplitViewController to load NSSplitViewItems otherwise.
In the attached project there are two split view controllers; one is set as the
content view controller of a window and it properly loads its split view items,
one created with instance of custom subclass named LeftViewController and the
other with an instance of another subclass named RightViewController. However,
the view property of the RightViewController contains a subview, in which I try
to add split view controlled by another split view controller. I do it in
RightViewController’s -viewDidLoad method and the code looks like this:
- (void)viewDidLoad
{
NSLog(@"-[%@ viewDidLoad]", self);
[self setSplitViewController:[[NSSplitViewController alloc]
initWithNibName:nil bundle:nil]];
NSSplitView *splitView = [[self splitViewController] splitView];
[[self containerView] addSubview:splitView];
[NSLayoutConstraint activateConstraints:[NSLayoutConstraint
constraintsWithVisualFormat:@"|-0-[splitView]-0-|" options:0 metrics:nil
views:NSDictionaryOfVariableBindings(splitView)]];
[NSLayoutConstraint activateConstraints:[NSLayoutConstraint
constraintsWithVisualFormat:@"V:|-0-[splitView]-0-|" options:0 metrics:nil
views:NSDictionaryOfVariableBindings(splitView)]];
NSViewController *viewController = [[RightLeftViewController alloc]
initWithNibName:nil bundle:nil];
[self addChildViewController:viewController];
NSSplitViewItem *splitViewItem = [NSSplitViewItem
splitViewItemWithViewController:viewController];
[[self splitViewController] addSplitViewItem:splitViewItem];
viewController = [[RightRightViewController alloc] initWithNibName:nil
bundle:nil];
[self addChildViewController:viewController];
splitViewItem = [NSSplitViewItem
splitViewItemWithViewController:viewController];
[[self splitViewController] addSplitViewItem:splitViewItem];
}
However, even though that inner split view is added into the split view
hierarchy, its controlling split view controller doesn’t load added split view
items (created with instances of yet another two subclasses
RightLeftViewController and RightRightViewController). Those two view
controllers (RightLeft and RightRight) never reach their respective
-viewDidLoad methods. Adding “inner” view controllers as “outer” view
controller children doesn’t make any difference.
It’s all in the project and it’s pretty simple. You can download it at
https://www.dropbox.com/s/8w0k2of88n1ksvw/SplitViewControllerTest.zip?dl=0
I’d appreciate any help and explanation why this doesn’t work. 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
Hierarchical split views and auto layout
I’m trying to implement rather complex UI, with a lot of views involved. The main window should contain one main view (module), which cannot be removed, and then users can add arbitrary number of additional specific views (modules) and arrange them on positions to their liking. Those additional views should also be resizable with user action, so I decided to use split views, which led to a view hierarchy with split views inside split views (inside split views…). The code use auto layout, thus NSSplitViewController and NSSplitViewItem instances. I’m having a problem which is probably related to assigning a particular holding priority values to particular split view items, in order to achieve desired resizing behaviour of involved views when window is resized and/or a particular split view divider dragged. Since it’s really hard to explain with words how UI looks and works (or should work) and what the problem is, I recorded a video (4:30 minutes) showing the issue. Please don’t mind a bit poor sound quality and my narrative skills. I gave my best to explain what’s happening. I’d be very thankful to anyone having the time to look at the video and try to figure out what could be the root of the problem. If after watching anyone has questions about implementation, code, etc, I’d be happy to provide more information. The link for the video: https://www.dropbox.com/s/1xbl5allc35b6l2/splitviews.mov?dl=0 One final note: in moments of desperation I considered implementing the whole UI without using auto layout and do all heavy work in split view’s delegate, but that would require major redesign and rewrite of current UI code that I quickly abandoned the idea. 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
Re: LSSharedFIleList API deprecated
On sre 09.12.2015., at 19.12, Greg Weston wrote: >> I opened a radar a while back and got this answer: >> >> "Shared file lists are no longer supported. There is no exact replacement >> API.” >> “If you want to manage your recent documents list, you should use >> NSDocumentController." >> “If you want to run a background tool independent of your main application, >> you should use a Launch Agent." >> >> My application already uses NSDocumentController; however, there is no means >> to remove a recent item from the list and my application uses >> LSSharedFileListItemRemove. I updated the radar with the need to remove >> recent items. No word yet. >> —kevin > > While not optimal, I would imagine this could be accomplished with a > combination of recentDocumentURLs, clearRecentDocuments: and > noteNewRecentDocumentURL:. Yeah, but I need to manage system-wide items, like favorites (found in Finder’s sidebar), recent document (on system level, not my application level), recent servers, etc. Finder still does that so I don’t really get the response that “shared file lists are no longer supported.” The existing API still works though, but being deprecated clearly shows in which direction things are moving. Is that yet another feature developers are stripped of so they couldn’t produce applications which mimic some of Apple’s applications features? -- 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
LSSharedFIleList API deprecated
This may not be the appropriate list to ask, but I couldn’t think of any better place… Now that (as of El Capitan) complete LSSharedFileList API is deprecated, which API is one supposed to use to retrieve list of items (in “favorites”, “recent documents”, “recent servers”, “login items” etc…) and do useful things with them (add/remove items from lists, resolve URLs, etc…)? Is there any public not-deprecated API to do that (preferably Obje-C or Swift)? I couldn’t find any useful info in El Capitan developer release notes. 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: Yet another autolayout question
On pet 13.11.2015., at 11.00, Ken Thomases wrote: > Hmm. Oh well. > > Your screencast of the failing case shows that you have some additional views > (boxes, it looks like) in the hierarchy, and you haven't explained fully the > constraints involved. Just to put some light onto this… I’ve just discovered everything works perfectly fine and as expected if I replace that instance of (subclassed) AVPlayerView with a simple custom NSView subclass (which just fills itself with a single colour) that implements intrinsicContentSize property. So, I suppose the culprit here is not my constraints, but those within the AVPlayerView, which apparently limits its size and breaks hugging and compression resistance properties. -- 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: Yet another autolayout question
On pet 13.11.2015., at 11.00, Ken Thomases wrote: > Your screencast of the failing case shows that you have some additional views > (boxes, it looks like) in the hierarchy, and you haven't explained fully the > constraints involved. I put those boxes just to give me some visual indication of how subviews are being resized. Their occupy their superviews completely, with a simple set of constraints: * box.leading = superview.leading * box.trailing = superview.trailing * box.top = superview.top * box.bottom = superview.bottom So, I believe they don’t matter in this case. > No, you misunderstand. > > The holding priority is how "strongly" the slider keeps its position, in > general. If you put a view into one pane and set its width and height at, > say, priority 750, and add constraints to keep its edges all around equal to > its superview's, then the user would be unable to drag the divider at all. > > Suppose the split view allowed the user to drag the divider. What happens > when the user lets go? The holding priority is less than the priorities of > the view's size constraints, so the view would push or pull the divider and > return to its desired size. Since the divider won't stay where the user put > it, it's best to not allow the user to drag it. > > In all probability, the drag is actually implemented by adjusting a > constraint whose priority is the holding priority, so it stops as dictated by > that priority. Ah okay, I didn’t realise that, but as I think of it, it does sound logical. However, even then I don’t understand why my particular case is failing. Let’s forget about the vertical splitView at the moment, and see what happens in the right of the window. Also, let’s say the superview of the playerView is high enough, so the previewView is on its intrinsic size. The holding priority of the top subview (containing the playerView) is 240 and for the bottom subview 260. The playerView content resistance priority in both directions is 230. As I drag the slider up, the vertical margins between the playerView and its superview are getting smaller, since the (required) constraints are set for them to be 20 or bigger. Once that limit is reached and they are required, they can’t go any smaller, so the size of the playerView comes into play. Since its compression resistance priority (230) is lower than that splitView's subview holding priority (as you’ve said, some invisible constraint implementing the drag with priority 240), I would expect the previewView to start shrinking. While doing so, maintaining its aspect ratio should not be a problem, since horizontal margins (their constraints) are set to be 20 or bigger. -- 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
Animating NSSplitViewItem with CAAnimation
I’m trying to use SplitViewController/NSSplitViewItem (both new in OS X 10.10) objects combo to control NSSplitView instances in my application. First off, even though I’ve got the latest version of Apple documentation installed, it completely omits NSSplitViewItem reference. That class is only mentioned in explanations of related methods of NSSplitViewController, but it’s nowhere really documented. I had to resort to class-dumping the AppKit in order to find out it’s interface. I’ll definitely file a bug for this. Now, into the subject. NSSplitViewItem implements NSAnimatablePropertyContainer protocol, which means one can use its animator proxy to animate animatable properties. The properly I’m interested in is “collapsed”, so that I can simultaneously animate collapsing/uncollapsing of a couple of subviews/item of the split view. I can easily do that using NSAnimationContext and running animation group(s) with completion handler(s). However, I need more control over animation execution. For example, it may happen a new animation is about to start before while the previous one is still in progress. In such case I need to interrupt/stop the previous animation before starting a new one. There are other situations as well, which require more tight control over animation execution. Simple NSAnimationContext animation group running doesn’t provide such flexibility, so I want to add/remove CAAnimation instances directly. However, NSSplitViewItem doesn’t have any CALayer backing up, so I don’t know how to use CAAnimation with it. Does anyone know more about this? -- 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
Finder Sync extension menu limitations
Hello, I wonder if anyone have got more experience developing Finder Sync extensions for Yosemite. I believe I figured out some things I’d like to achieve aren’t possible and I’d like to confirm them. It’s related to FIFinderSync protocol method - [FIFinderSync menuForMenuKind:]. According to documentation, in this method I’m supposed to create a menu containing menu items, which are related to selected and/or target items in one of monitored directories. That menu (that is, its items) will be added to Finder standard contextual menu (provided that FIMenuKind parameter is FIMenuKindContextualMenuForItems). This all works fine, but I’ve noticed that not exactly menu items I created in above mentioned method are added to contextual menu, but their “shallow copies. I say “shallow”, because, as far as I can see, only three properties of original menu items are used: title, image and action. All other properties I set to menu items in the protocol method aren’t used, including target, indentation, tag, represented object, etc. Therefore, “shallow menu items that appear in Finder contextual menu have their targets set to nil, which means all menu item actions have to be implemented by the FIFinderSync subclass. This, as well as impossibility to pass menu items tags and represented objects, disturbs my code organisation a bit, but I can work around it. But one particular things really bothers me; if I create a menu item which has its own submenu, the “shallow” menu item added to the contextual menu does not include that submenu, effectively preventing one from creating hierarchical menus provided by Finder Sync extension. My extension is supposed to provide quite some number of actions (depending on selection), many of them are logically grouped and not being able to organise them in hierarchical menu really clutters the whole Finder contextual menu with too many items. Another interesting thing is that if in the action method of a certain “shallow” menu item I try to get a reference to its containing menu (practically trying to get reference to Finder contextual menu), that property returns nil, like the item doesn’t belong in to any menu at all. If anyone realises I’m doing anything wrong, or knows how to overcome these limitations, I’d be really thankful for eventual 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
Re: All buttons lost focus ring on Yosemite
On čet 12.03.2015., at 19.15, Chris Cianflone wrote: Hi all, We had a similar issue. When running on Yosemite the same thing would happen to us with the focus rings not displaying. Don't know if this helps in your case, but the fix for us was to stop building with the 10.7 SDK. Moving to the 10.8 SDK fixed the problem for us. (Don't ask why we are using such old SDKs, and only moved to 10.8 instead of 10.9 or 10.10, that's another story for another time.) You can see this in a simple Cocoa app too started from an Xcode template. Thanks for the head up, that’s definitely it. Our application is also built with the 10.7 SDK. At one moment of desperation I had a thought this could be the issue, because I had similar problems (small bugs introduced) with QuickLook when Mavericks came out, which disappeared if the application was build with 10.8 or 10.9 SDK. Unfortunately, for various reasons se still need to support a bunch of 10.7 users (also another story for another time”), so I can’t just simply build with the 10.8 SDK. We’ll probably introduce a parallel version which ditches 10.7 SDK while still maintaining the old one. On čet 12.03.2015., at 20.39, Kyle Sluder wrote: Have you filed a Radar about that? I will, as soon as I’m able to login into Apple bug reporter, it seems to have some problems at the moment. -- 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
NSWorkspace (un)mount notification in an XPC service
Hi all, Documentation states many of NSWorkspace methods cannot be used in a sandboxed application. I wonder if that applies to registering and receiving NSWorkspaceDidMountNotification and NSWorkspaceDidUnmountNotification notifications. I have a situation in which a sandboxed application (with no other entitlements) contains a Finder Sync extension. The extension is also sandboxed (with no other entitlements) and it contains an XPC service. The XPC service is sandboxed, with one additional entitlement: com.apple.security.temporary-exception.files.absolute-path.read-only = “/“ If I register to receive NSWorkspaceDidMountNotification and NSWorkspaceDidUnmountNotification in either the application or the extension, it works, notification are received correctly. However, if I register exactly the same in the same way in the the XPC service, there are no notifications received. I also don’t get any error nor logging message when registering for those notifications in the XPC service. Is this related to XPC service limitations or sandboxing limitations (I suppose the former, since notifications are received in the application and extension, which are also sandboxed)? -- 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: All buttons lost focus ring on Yosemite
On uto 17.03.2015., at 16.39, Kyle Sluder wrote: Just so you know, you can link against the 10.8 SDK and set your minimum deployment target to 10.7. Thanks, you were, like, one minute faster than me with my additional reply. -- 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: All buttons lost focus ring on Yosemite
On uto 17.03.2015., at 16.11, Dragan Milić wrote: On čet 12.03.2015., at 19.15, Chris Cianflone wrote: Hi all, We had a similar issue. When running on Yosemite the same thing would happen to us with the focus rings not displaying. Don't know if this helps in your case, but the fix for us was to stop building with the 10.7 SDK. Moving to the 10.8 SDK fixed the problem for us. (Don't ask why we are using such old SDKs, and only moved to 10.8 instead of 10.9 or 10.10, that's another story for another time.) You can see this in a simple Cocoa app too started from an Xcode template. Thanks for the head up, that’s definitely it. Our application is also built with the 10.7 SDK. At one moment of desperation I had a thought this could be the issue, because I had similar problems (small bugs introduced) with QuickLook when Mavericks came out, which disappeared if the application was build with 10.8 or 10.9 SDK. Unfortunately, for various reasons se still need to support a bunch of 10.7 users (also another story for another time”), so I can’t just simply build with the 10.8 SDK. We’ll probably introduce a parallel version which ditches 10.7 SDK while still maintaining the old one. OK, at least I discovered that changing build settings to SDKROOT = macosx10.8 and MACOSX_DEPLOYMENT_TARGET = 10.7” solves the problem too, so that will suffice for the time being. -- 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: All buttons lost focus ring on Yosemite
My previous message sent to the list apparently didn’t get admin approval, there were two attached images showing standard alarm panels with buttons which don’t draw their focus ring. Therefore, in this message I’ll combine answers to both Kyle and Graham. On pon 09.03.2015., at 17.48, Kyle Sluder wrote: I'd start by looking at that -[NSView(NTExtensions) drawFocusRing] method. If you comment it out, what happens? No changes :-( I even went that far to remove the category completely and ignore all compiler warnings where added methods were used. Now, that would normally throw exceptions, but before even loading any application window and using any view requiring added category methods, the application shows two alert panels (one by one, attached images of those panels is the reason my previous message didn’t get through ), depending on current user preferences. That enables me to see buttons' behaviour even before any exception is thrown. Here is the link to the image of the first alert panel: http://media.cocoatech.com/first_alert.png What’s interesting here is that, as you can see, the alert’s suppressionButton checkbox DOES draw its focus ring, but other two buttons don’t! Believe my words, if I use tab/shift+tabs to change focus on them, they are focused (I can then activate them with the space), but the focus ring is not drawn, only the checkbox gets it correctly. Immediately after that first alert is dismissed, the second one appears, here is the link: http://media.cocoatech.com/second_alert.png With this one, even the focused suppressionButton checkbox doesn’t draw its focus ring. Other two buttons don’t too. And all this is with the NSView category completely removed. There are other NSView or NSControl or NSButton or NSButtonCell categories defined. The code defining both alarm panels is pretty standard, I can post it if necessary. Everything worked well in Mavericks, I’ve got no idea what happened in the meanwhile. For safety, you really ought to be prefixing all of your category methods with some unique-to-you prefix. Yeah. As I’ve mentioned already, this is not my code, it was first created back in 2002 and until this problem I haven’t even looked into it. On uto 10.03.2015., at 00.44, Graham Cox wrote: In Xcode, add OBJC_PRINT_REPLACED_METHODS (value: YES) to your scheme's environment variables. Then all of the methods replaced by categories are logged when your app launches. While the list can be long and might take some time to go through, it will show you if any of your category methods are replacing anything - it's a much more reliable way to check than doing a class dump. Thanks for the suggestion Graham, I’ll do that. It’s be interesting to see if and what methods are replaced, although I don’t think it’ll solve this particular problem. I mentioned above it still happens even with the NSView category completely removed. If you're not using those category methods, remove them. Most of them seem to be convenience methods that are possible nice to haves rather than vital to use NSView. Some appear to me to wholly misunderstand how a view stack (involving semi-transparancy for example) is actually drawn. Others are things that could be useful in particular circumstances but you probably wouldn't want to apply to every view your app ever instantiates including framework ones. For those custom views of yours that use these things, relocate that code to the custom view. It may mean a small duplication of code across a few different views, but it will be a lot safer than swapping out NSView wholesale. NSView just may be Cocoa's single most complicated class (any other contenders?). As a result, you probably can't foresee all possible effects of adding a category on it. As mentioned above, I’ve never looked into that code before this problem started. Now that I do, I’ll definitely do something about it and apply your suggestions. -- 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: All buttons lost focus ring on Yosemite
On pon 09.03.2015., at 16.33, Motti Shneor wrote: Date: 9 במרץ 2015 בשעה 11:58:11 GMT+2 From: Dragan Milić mi...@mac.com Subject: Re: All buttons lost focus ring on Yosemite To: Cocoa-dev cocoa-dev@lists.apple.com On pet 06.03.2015., at 18.37, Kyle Sluder wrote: On Fri, Mar 6, 2015, at 10:49 AM, Dragan Milić wrote: Thanks for the suggestion. A bad category was something I also thought could be the reason for this behaviour, but it looks like it isn’t. There are no NSButton, NSButtonCell, nor NSControl categories. There is a single NSView category, but it doesn’t do anything related to drawing, it just defines and implements some convenient methods for finding subviews and superviews of a certain class. Please post the code for this category. Maybe it's colliding with an internal implementation detail of the focus ring mechanism. Sure, no problem. Since it’s a bit long, I attached it as a separate ObjC source file. A few notes: * It’s rather old code (not made by me) that I haven’t looked into for years until this problem appeared. * I rearranged it a bit for easier reading, so there may be some copy/paste/typo errors, but you should get the overall idea what it does. * All drawing related code is contained within unique methods, no overriding. * I was “lying”, there is a small NSButton category (defined within the same file), but it just checks if a button is of a checkbox type. Thanks for looking into this, as I really hit a dead end with it. NSView-NTExtensions.m Your category NSView+NTExtensions defines “drawFocusRing” and overrides LOTS of native NSView methods… Which native NSView methods are overridden? Perhaps I’m missing something, but I’ve just class-dumped AppKit and I haven’t found any overridden method (including private ones) of NSView and only a few of completely unrelated classes (like -(BOOL)isVIsible, for example). “-(void)drawFocusRing is defined for usage with some custom NSView subclasses spread all over through the application, to make them draw their specific focus ring. these changes in the category apply to ALL views, including your NSButtons. Yeah, I know that. You could verify very simply by setting a breakpoint in your “drawFocusRing” method, and see if one of your buttons actually executes this method instead of the original. Nope, unfortunately it’s not that easy. Also, like I’ve mentioned in the first post in this thread, just defining simple NSAlert with default three buttons (so, they are completely drawn by the AppKit and should not use any added methods of my category) causes corresponding alert panel to draw its buttons without a focus ring. It is not recommended to mess with the NSView or NSWindow behavior, because we don’t know what Apple is doing in their implementation. Well, the application is not that simple and requires a lot of things APIs don’t provide out-of-the-box. Also, I don’t see defining unique methods in a NSView category like messing with NSView behaviour. Something is certainly messed up, but I don’t see this category being the reason. If I’m wrong I’d be really thankful if someone pinpoints errors in the provided code. -- 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: All buttons lost focus ring on Yosemite
On pet 06.03.2015., at 18.37, Kyle Sluder wrote: On Fri, Mar 6, 2015, at 10:49 AM, Dragan Milić wrote: Thanks for the suggestion. A bad category was something I also thought could be the reason for this behaviour, but it looks like it isn’t. There are no NSButton, NSButtonCell, nor NSControl categories. There is a single NSView category, but it doesn’t do anything related to drawing, it just defines and implements some convenient methods for finding subviews and superviews of a certain class. Please post the code for this category. Maybe it's colliding with an internal implementation detail of the focus ring mechanism. Sure, no problem. Since it’s a bit long, I attached it as a separate ObjC source file. A few notes: * It’s rather old code (not made by me) that I haven’t looked into for years until this problem appeared. * I rearranged it a bit for easier reading, so there may be some copy/paste/typo errors, but you should get the overall idea what it does. * All drawing related code is contained within unique methods, no overriding. * I was “lying”, there is a small NSButton category (defined within the same file), but it just checks if a button is of a checkbox type. Thanks for looking into this, as I really hit a dead end with it. NSView-NTExtensions.m Description: Binary data -- 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: All buttons lost focus ring on Yosemite
On uto 17.02.2015., at 01.04, Corbin Dunn wrote: On Feb 12, 2015, at 6:40 AM, Dragan Milić wrote: I’m dealing with a rather strange issue. When running my application on Yosemite, all buttons lose focus ring (when having focus). When I say all, I mean absolutely ALL buttons, even those in standard alert panels and sheets. I can move focus between buttons using keyboard without any problem (provided that pressing tab is set to move focus between “All controls” in the Keyboard System Preferences), it’s just that a button currently having focus doesn’t draw its focus ring. Focus rings of text fields and lists are drawn as expected. When running exactly the same application bundle under Mavericks (and earlier), everything seems fine, button focusses are shown as expected. I’d really appreciate any help in solving this mysterious problem. Thanks in advance. Sounds like you have added a bad category on NSButton, NSButtonCell, NSControl or NSView that overrides some default behavior. corbin My apologies for responding after such a long delay. I was on a winter holiday and I returned from it injured, so I really haven’t spent much time working or in front of my computer during the past four weeks. Thanks for the suggestion. A bad category was something I also thought could be the reason for this behaviour, but it looks like it isn’t. There are no NSButton, NSButtonCell, nor NSControl categories. There is a single NSView category, but it doesn’t do anything related to drawing, it just defines and implements some convenient methods for finding subviews and superviews of a certain class. I’m still trying to figure out what’s going on and why this happens. -- 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
All buttons lost focus ring on Yosemite
I’m dealing with a rather strange issue. When running my application on Yosemite, all buttons lose focus ring (when having focus). When I say all, I mean absolutely ALL buttons, even those in standard alert panels and sheets. I can move focus between buttons using keyboard without any problem (provided that pressing tab is set to move focus between “All controls” in the Keyboard System Preferences), it’s just that a button currently having focus doesn’t draw its focus ring. Focus rings of text fields and lists are drawn as expected. When running exactly the same application bundle under Mavericks (and earlier), everything seems fine, button focusses are shown as expected. I’d really appreciate any help in solving this mysterious problem. 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
NSSpellChecker exception
I'm getting exception reports from users of an application I'm working on that I cannot reproduce. The exception comes from the NSSpellChecker instance, and the trace looks something like this: NSObjectInaccessibleException NSDistantObject (0x62279bc0) is invalid (no connection) 0x7fff91c61aee 0x7fff8a9fde75 0x7fff916dd10c 0x7fff92f6d6f9 0x7fff9163b0f4 0x7fff9163aea8 0x7fff89151a0c 0x7fff88cda673 0x7fff88cd8664 0x7fff92ef38a1 0x7fff92ef354b 0x7fff9030c28d 0x7fff9030e673 0x7fff9030f9c1 0x7fff9030df87 0x7fff9030f177 0x7fff8d984ef8 0x7fff8d987fb9 NSExceptionHandlerExceptionRaiser (in ExceptionHandling) + 172 objc_exception_throw (in libobjc.A.dylib) + 43 +[NSException raise:format:] (in CoreFoundation) + 204 -[NSDistantObject forwardInvocation:] (in Foundation) + 291 ___forwarding___ (in CoreFoundation) + 452 _CF_forwarding_prep_0 (in CoreFoundation) + 120 -[NSSpellChecker _checkSpellingAndGrammarInString:range:enclosingRange:offset:types:options:orthography:inSpellDocumentWithTag:mutableResults:wordCount:] (in AppKit) + 2071 NSSpellCheckerCheckString (in AppKit) + 8096 -[NSTextCheckingOperation main] (in AppKit) + 152 -[__NSOperationInternal _start:] (in Foundation) + 631 __NSOQSchedule_f (in Foundation) + 64 _dispatch_client_callout (in libdispatch.dylib) + 8 _dispatch_queue_drain (in libdispatch.dylib) + 451 _dispatch_queue_invoke (in libdispatch.dylib) + 110 _dispatch_root_queue_drain (in libdispatch.dylib) + 75 _dispatch_worker_thread2 (in libdispatch.dylib) + 40 _pthread_wqthread (in libsystem_pthread.dylib) + 314 start_wqthread (in libsystem_pthread.dylib) + 13 Most of the time it comes from the -[NSSpellChecker _checkSpellingAndGrammarInString:range:enclosingRange:offset:types:options:orthography:inSpellDocumentWithTag:mutableResults:wordCount:] method, but sometimes from -[NSSpellChecker setIgnoredWords:inSpellDocumentWithTag:]. Also, sometimes the exception is NSPortTimeoutException (connection timeout: did not receive reply), but still related to DOs. The thing is I don't use NSSpellChecker in the application at all. As expected, there are a lot of NSTextField and a few NSTextView instances, but NSSpellChecker is not used directly. Users say exceptions happen in different situations, but mostly when doing something that requires typing into a text field. I do use distributed objects though, to communicate with external helper tools which execute some certain tasks. Connection objects for that communication are created and destroyed as needed. I have created a startup item which runs a DTrace script and prints names and PIDs of processes making any kind of mach_port call, but that didn't give me any clue of why this is happening. I've also list's archive and I couldn't find anything related to this, but I hope someone might have a clue of what's really happening here. -- Dragan -- 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: NSSpellChecker exception
On sre 13.08.2014., at 02.30, Douglas Davidson wrote: NSSpellChecker uses DO to connect with the spellchecker process. It properly handles any exceptions that may result, so these exceptions would be caught and handled and you do not need to be reporting them. Thanks, so they can be safely ignored. Does that also apply to similar exceptions (much rarely reported) related to DO and coming from: -[IMKInputSession activate] (in HIToolbox) resulting in NSPortTimeoutException: connection timeout: did not receive reply and -[IMKInputSession deactivate] (in HIToolbox)resulting in NSInvalidSendPortException: [NSMachPort sendBeforeDate:] destination port invalid ??? -- 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
CGContext... logging messages
A couple of users have reported getting quite some (sometimes a lot, like hundreds or thousands) logging errors coming from my application (OS X). The logs state something like this: : CGContextRotateCTM: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update. The functions causing the problems are different though. Users got examples of CGContextSetFillColorWithColor(), CGContextSetStrokeColorWithColor(), CGContextScaleCTM(), CGContextConcatCTM(), CGContextGetCTM(), CGContextRestoreGState() and others. I don't use any of those functions in my code directly, all the drawing is done using Cocoa, so I suppose Cocoa methods are calling those CG functions under the hood. I also took care of saving and restoring the current graphics context wherever necessary. On top of it all, these happen only with few users (who reported the problem, there are probably some more), but certainly not with all. I'd definitely know if it's a common problem, since the application user base is measured with a six-digit number. I don't have this problem myself so I set symbolic breakpoints in order to try to track it down, but it didn't really work, as those functions are being called way too often to give me any hint where the problem could be. Perhaps a useful information is while people are getting those messages, there's nothing really wrong with the way application draws its UI. Everything looks normal. I also tried searching mail list archive for similar issues, and while I found some discussions, they weren't quite relevant, as people had particular test cases where the issue was 100% reproducible (and many times the problem was in the API itself), or it was related to bugs in iOS. Does anyone know what could be causing this problem in such a way that it doesn't happen to all, but only to some people? Is it possible to get the graphics context completely screwed so that those messages start popping-up? -- 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
QTMovieLayer in IKImageBrowserCell
Is it possible to set a QTMovieLayer (yes, I know it's deprecated in 10.9) as the IKImageBrowserCellForegroundLayer of an IKImageBrowserCell? If I do so in cell's -layerForType: method and then play a movie associated with the layer, I can hear the audio track, but there's no movie rendering above cell's image. -- 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
IKImageBrowserView, drawing on layers and retina display
I'm trying to use IKImageBrowser class for something which is supposed to
resemble Finder's icon view appearance. Hence, I need quite customized item
titles, e.g. multiline string, oval gradient background (like Finder's label
indicators), etc. Customizing item's title frame and views title (setting
custom paragraph style with custom truncating etc.) didn't give any results,
item titles remained single-lined. And besides, I would't be able to do
anything about other graphics element, which are part of item's title in my
case.
Therefore I took an approach to drive item titles myself in the item's cell
background (IKImageBrowserCellBackgroundLayer) layer. I supplied a custom
CALayer for that layer and implemented it's drawing delegate method. Here's how
that code looks like:
- (CALayer *)layerForType:(NSString *)aType
{
if ([aType isEqualToString:IKImageBrowserCellBackgroundLayer])
{
CALayer *result = [CALayer layer];
[result setDelegate:self];
[result setFrame:[self frame]];
[result setName:aType];
[result setNeedsDisplay];
return result;
}
return [super layerForType:aType];
}
- (void)drawLayer:(CALayer *)aLayer inContext:(CGContextRef)aContext
{
if ([[aLayer name] isEqualToString:IKImageBrowserCellBackgroundLayer])
{
// Set the current context.
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:[NSGraphicsContext
graphicsContextWithGraphicsPort:aContext flipped:[self imageBrowserView]]];
// Draw here...
[NSGraphicsContext restoreGraphicsState];
}
}
This works fine in general, but I'm facing two problems I can't find a way to
solve:
1. All string drawing in the cell's background layer appear without
antialiasing. Other drawing (Bezier Paths, images…) produce expected results.
2. All drawing in the cell's background layer in NOT retina-compliant! Not
strings, not any other drawing.
I should note that I used standard NSImage, NSBezierPath and NSString drawing
methods. Drawing exactly the same contents with the same code in a custom view
produces expected results (antialiased strings, all fine on both non-retina and
retina screens).
I haven't done many things with CALayers in the past, so maybe I'm missing some
setting to make this work, but it doesn't look like that looking at that class'
public API. On the other hand I find it hard to believe that IKImageBrowserView
custom drawing onto its layers is not retina-compliant!
If necessary, I can provide sample snapshots of results on displays of both
type.
Hopefully will someone know how to solve this. 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
Re: IKImageBrowserView, drawing on layers and retina display
Okay, replying to myself here… On pon 10.02.2014., at 10.30, Dragan Milić wrote: I haven't done many things with CALayers in the past, so maybe I'm missing some setting to make this work, but it doesn't look like that looking at that class' public API. On the other hand I find it hard to believe that IKImageBrowserView custom drawing onto its layers is not retina-compliant! Setting layer's contentsScale like: [result setContentsScale:self imageBrowserView] window] screen] backingScaleFactor]]; solves the retina issue! Drawing on retina displays works fine now. The remaining issue is that strings drawn on the layer (using standard string drawing methods) still don't have antialiasing. -- 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: IKImageBrowserView, drawing on layers and retina display
Again replying to myself… On pon 10.02.2014., at 11.59, Dragan Milić wrote: The remaining issue is that strings drawn on the layer (using standard string drawing methods) still don't have antialiasing. This is also solved, perhaps it may help someone else to: https://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CATextLayer_class/Introduction/Introduction.html If a text is drawn on a non-opaque (transparent) background on a layer, it won't be antialiased. An opaque background on the layer (at least in the frame where the text will be drawn) is needed for antialiased text. -- 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
Notification Center settings
Hi all, Is there any API (or any other way) to read user settings for the Notification Center in OS X 10.8 (e.g. whether user notifications are enabled for a particular application)? The only thing I can find is some kind of database (.db) file located in the ~/Library/Application Support/Notification Center folder, but I have no idea what its format is (SQLite perhaps) and how to extract any useful data from 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
Crashes in com.apple.QuickLookFramework/com.apple.QuickLookUIFramework
I use QL API in my application to preview all kind of files (the application is actually a kind of file browser). Before going into real problems, I just want to say I'm just using simple QLPreviewPanel, no hacks or tweaks of any kind. Also, I'm not using any private or non-documented APIs. I also implemented an object that implements QLPreviewPanelController protocol, which also serves as panels delegate and data source, so is also implements all required methods an object implementing QLPreviewPanelDelegate and QLPreviewPanelDataSource protocols (I can send code showing implementation of this object, if necessary). However, users report quite some crashes, which involve QLPreviewPanelController. There are three types of crashes, so I'll post them all here. This is the first type of crashes: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Application Specific Information: objc[345]: garbage collection is OFF abort() called Assertion failure in -[QLPreviewPanelController _updatePanelFrame:animate:] (line 586): unreachable code Application Specific Signatures: [QL] -[QLPreviewPanelController _updatePanelFrame:animate:]: unreachable code Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fff8dcfdce2 __pthread_kill + 10 1 libsystem_c.dylib 0x7fff9477a7d2 pthread_kill + 95 2 libsystem_c.dylib 0x7fff9476ba7a abort + 143 3 com.apple.QuickLookFramework 0x7fff97e5d745 _QLCrash + 175 4 com.apple.QuickLookFramework 0x7fff97e5d82b _QLRaiseAssert + 230 5 com.apple.QuickLookUIFramework 0x7fff90097ec8 -[QLPreviewPanelController _updatePanelFrame:animate:] + 444 6 com.apple.QuickLookUIFramework 0x7fff9008e9be -[QLPreviewPanelController previewView:didShowDisplayable:] + 353 7 com.apple.QuickLookUIFramework 0x7fff900b1584 -[QLPreviewView _setDisplayable:transition:] + 2236 8 com.apple.QuickLookUIFramework 0x7fff900b17a0 -[QLPreviewView _updateDisplayableWithTransition:] + 289 9 com.apple.QuickLookUIFramework 0x7fff900b1f19 -[QLPreviewView _setDisplayedDocument:transition:] + 563 10 com.apple.QuickLookUIFramework 0x7fff900b3378 -[QLPreviewView _timedOut] + 339 11 com.apple.Foundation 0x7fff9263d1aa __NSFireDelayedPerform + 392 12 com.apple.CoreFoundation 0x7fff91102c24 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 13 com.apple.CoreFoundation 0x7fff91102776 __CFRunLoopDoTimer + 534 14 com.apple.CoreFoundation 0x7fff910e3001 __CFRunLoopRun + 1617 15 com.apple.CoreFoundation 0x7fff910e2676 CFRunLoopRunSpecific + 230 16 com.apple.HIToolbox0x7fff9329c31f RunCurrentEventLoopInMode + 277 17 com.apple.HIToolbox0x7fff932a35c9 ReceiveNextEventCommon + 355 18 com.apple.HIToolbox0x7fff932a3456 BlockUntilNextEventMatchingListInMode + 62 19 com.apple.AppKit 0x7fff8c98cf5d _DPSNextEvent + 659 20 com.apple.AppKit 0x7fff8c98c861 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 21 com.apple.AppKit 0x7fff8c98919d -[NSApplication run] + 470 22 com.apple.AppKit 0x7fff8cc07b88 NSApplicationMain + 867 23 com.cocoatech.PathFinder 0x0001e764 0x1 + 59236 The stack trace is not always the same, but it always ends with the following calls: 0 libsystem_kernel.dylib 0x7fff8dcfdce2 __pthread_kill + 10 1 libsystem_c.dylib 0x7fff9477a7d2 pthread_kill + 95 2 libsystem_c.dylib 0x7fff9476ba7a abort + 143 3 com.apple.QuickLookFramework 0x7fff97e5d745 _QLCrash + 175 4 com.apple.QuickLookFramework 0x7fff97e5d82b _QLRaiseAssert + 230 5 com.apple.QuickLookUIFramework 0x7fff90097ec8 -[QLPreviewPanelController _updatePanelFrame:animate:] + 444 Is this a bug in QuickLook framework (unreachable code), or am I doing something wrong here? If it's my fault, any hint on what I'm doing wrong is highly appreciated. This is the second type of crashes: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Application Specific Information: objc[193]: garbage collection is OFF abort() called Assertion failure in -[QLPreviewCacheManager cacheRecentDocument:] (line 161): document.displayBundle.visibility == QLPreviewHiddenVisibilityState Application Specific Signatures: [QL] -[QLPreviewCacheManager cacheRecentDocument:]: document.displayBundle.visibility == QLPreviewHiddenVisibilityState Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0
Re: Sudden and hard to reproduce crashes in libcache
Just an update on this issue: On čet 23.02.2012., at 20.00, Greg Parker wrote: Yep, that's CFRelease(NULL), plus ExceptionHandling.framework catching the Unix signal and trying to turn it into an Objective-C exception. That background thread is part of NSCache. This could be a bug in your use of NSCache, a memory smasher somewhere, or a bug in NSCache itself. You may be able to reproduce this by forcing the app into a low memory situation. That background thread is evicting NSCache contents in responds to low memory. Once you can reproduce, you should try zombies and guard malloc. Apparently, it's a bug in NSCache. On http://files.me.com/milke/t5ufx5 can you find a super simple sample app to reproduce it every time without any problem. It looks like -[NSString stringWithFormat:] (and possibly other calls) can return the same pointer rather than creating new object every call. Perhaps it's trying to reuse strings to save memory? NSCache seems not to like that and crashes. If I wrap the strings in a simple holder object, which has nothing more than a string as it's content ivar, that solves the crashing problem. But it's still completely incorrect behaviour on NSCache part. I think this makes NSCache (at the moment) almost unusable in real world applications, because you never now whether and when it's going to crash. Maybe never, maybe immediately. I encourage everyone (especially those using NSCache) to file a bug report to Apple. If they get a lot of duplicates on the same issue, they may hopefully do something quicker. NSCache was introduced for object caching and memory saving and having to wrap every cached object in a holder object defies cache's purpose (kind of). -- 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
Sudden and hard to reproduce crashes in libcache
First of all, I apologise if this is not the right topic for this list. Some beta testers of an application I'm working on experience rather strange and sudden crashes, very often when the application is doing nothing, just sitting idle in the background. The crash happens in a thread named com.apple.root.default-priority and it's not even controlled by the application. As far as I figure it out, it is triggered by the system to release some memory from caches the application uses. This is the part of the crash report related to that particular thread: Thread 8 Crashed:: Dispatch queue: com.apple.root.default-priority 0 libsystem_kernel.dylib 0x7fff8d847ce2 __pthread_kill + 10 1 libsystem_c.dylib 0x7fff9009e7d2 pthread_kill + 95 2 libsystem_c.dylib 0x7fff9008fa7a abort + 143 3 libc++abi.dylib 0x7fff8a1e77bc abort_message + 214 4 libc++abi.dylib 0x7fff8a1e4fcf default_terminate() + 28 5 libobjc.A.dylib 0x7fff8a69a1b9 _objc_terminate + 94 6 libc++abi.dylib 0x7fff8a1e5001 safe_handler_caller(void (*)()) + 11 7 libc++abi.dylib 0x7fff8a1e505c std::terminate() + 16 8 libc++abi.dylib 0x7fff8a1e6152 __cxa_throw + 114 9 libobjc.A.dylib 0x7fff8a699e7a objc_exception_throw + 327 10 com.apple.CoreFoundation0x7fff8c8b92a9 -[NSException raise] + 9 11 com.apple.ExceptionHandling 0x000100332e0a NSExceptionHandlerUncaughtSignalHandler + 37 12 libsystem_c.dylib 0x7fff900f0cfa _sigtramp + 26 13 com.apple.CoreFoundation0x7fff8c793c0b CFRelease + 27 14 libcache.dylib 0x7fff8fb4d8e4 _value_entry_remove + 142 15 libcache.dylib 0x7fff8fb4d9cd _entry_unmap + 81 16 libcache.dylib 0x7fff8fb4da71 _entry_evict + 153 17 libcache.dylib 0x7fff8fb4db04 _evict_last + 106 18 libcache.dylib 0x7fff8fb4dcf2 _cache_enforce_limits + 34 19 libcache.dylib 0x7fff8fb4dea5 cache_handle_memory_pressure + 125 20 libdispatch.dylib 0x7fff888bf2b6 _dispatch_source_invoke + 635 21 libdispatch.dylib 0x7fff888bbf77 _dispatch_queue_invoke + 71 22 libdispatch.dylib 0x7fff888bb760 _dispatch_worker_thread2 + 198 23 libsystem_c.dylib 0x7fff9009e3da _pthread_wqthread + 316 24 libsystem_c.dylib 0x7fff9009fb85 start_wqthread + 13 All those crash reports for the crashing thread look the same. Only a few people experience them, but regularly. For others, it practically impossible to reproduce. I'm using higher level Cocoa NSCache API to cache objects. Cached objects are various image representations and much rarely attributed strings and NSNumber instances. I see the crash happens after CFRelease() call, but I can't figure out why. If I try to do CFRelease(NULL), I get almost the same sequence, similar to: 3 libc++abi.dylib 0x7fff8a1e77bc abort_message + 214 4 libc++abi.dylib 0x7fff8a1e4fcf default_terminate() + 28 5 libobjc.A.dylib 0x7fff8a69a1b9 _objc_terminate + 94 6 libc++abi.dylib 0x7fff8a1e5001 safe_handler_caller(void (*)()) + 11 7 libc++abi.dylib 0x7fff8a1e505c std::terminate() + 16 8 libc++abi.dylib 0x7fff8a1e6152 __cxa_throw + 114 9 libobjc.A.dylib 0x7fff8a699e7a objc_exception_throw + 327 10 com.apple.CoreFoundation0x7fff8c8b92a9 -[NSException raise] + 9 11 com.apple.ExceptionHandling 0x000100332e0a NSExceptionHandlerUncaughtSignalHandler + 37 12 libsystem_c.dylib 0x7fff900f0cfa _sigtramp + 26 But I don't know who and why does (if at all) that NULL pointer release. The documentation for libcache says Calling cache functions from cache callbacks should be avoided to prevent deadlock. I thought maybe when releasing cached objects libcache calls callback methods to release memory and then image representations are doing some caching on their own, which would effectively be calling cache functions from cache callbacks. But this is just a wild guess, I've no idea what is really going on. So, I'd really appreciate if anyone can help me with this. I've got no idea whether it's a but in the application, or the OS. If necessary, I can send the full crash report and also explain what object are being cached using NSCache. -- Dragan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the
Re: Connect to server - list of shared volumes
On pet 21.10.2011., at 15.41, Dragan Milić wrote: Hello, This may not be strictly related to Cocoa, but I'm willing to use any API that can serve the purpose and perhaps something like that exists in Cocoa, I just don't know of it. So, I want to mount shared volume(s) that reside on the same server. I use FSMountServerVolumeAsync() function, supplying it the URL of the server, as one of arguments. As I understand, this function loads and runs the appropriate URLMount plug-in, which structure is private. If there are move mountable volumes connected to the server, this plug-in automatically presents a modal panel with the list of all available servers and allows user to choose which one to connect to. I want to skip this magic provided by the API and to create this list of available mountable volumes myself (e.g. I may choose to exclude some from the list or do something else). Is there a public way to retrieve a list of mountable volumes connected to the server, which full URL is known? If not, I'll be also satisfied if I can do it in undocumented way, using any private API. Any hints anyone? -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Connect to server - list of shared volumes
On pet 21.10.2011., at 15.41, Dragan Milić wrote: Hello, This may not be strictly related to Cocoa, but I'm willing to use any API that can serve the purpose and perhaps something like that exists in Cocoa, I just don't know of it. So, I want to mount shared volume(s) that reside on the same server. I use FSMountServerVolumeAsync() function, supplying it the URL of the server, as one of arguments. As I understand, this function loads and runs the appropriate URLMount plug-in, which structure is private. If there are move mountable volumes connected to the server, this plug-in automatically presents a modal panel with the list of all available servers and allows user to choose which one to connect to. I want to skip this magic provided by the API and to create this list of available mountable volumes myself (e.g. I may choose to exclude some from the list or do something else). Is there a public way to retrieve a list of mountable volumes connected to the server, which full URL is known? If not, I'll be also satisfied if I can do it in undocumented way, using any private API. Any hints anyone? -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Connect to server - list of shared volumes
Hello, This may not be strictly related to Cocoa, but I'm willing to use any API that can serve the purpose and perhaps something like that exists in Cocoa, I just don't know of it. So, I want to mount shared volume(s) that reside on the same server. I use FSMountServerVolumeAsync() function, supplying it the URL of the server, as one of arguments. As I understand, this function loads and runs the appropriate URLMount plug-in, which structure is private. If there are move mountable volumes connected to the server, this plug-in automatically presents a modal panel with the list of all available servers and allows user to choose which one to connect to. I want to skip this magic provided by the API and to create this list of available mountable volumes myself (e.g. I may choose to exclude some from the list or do something else). Is there a public way to retrieve a list of mountable volumes connected to the server, which full URL is known? If not, I'll be also satisfied if I can do it in undocumented way, using any private API. 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Dynamic Services menu, CM plug-in alternatives
Hello everyone, I'd firstly like just to mention that I'm not a premium ADC member and I've had the bare bones Snow Leopard 10A380 build (passed as a asset from a fellow developer, who is a premium member), without any new developer tools or documentation,... So I don't have full insight in all the news and changes in APIs and frameworks. What I do know is that the new Cocoa Finder doesn't even try to load my contextual menu plug-in, regardless of the architecture its binary contains (32-bit, 64-bit). According to this: http://lists.apple.com/archives/Carbon-dev/2009/Apr/msg00074.html thread, There is currently no way to extend contextual menus in 64- bit apps. Snow Leopard includes some significant enhancements to the Services architecture that are designed to partially replace the capabilities of contextual menus. and As far as I know, it was made for exactly the reason I specified - the Cocoa team really doesn't want to load arbitrary code into every Cocoa process because of the risk of malware being loaded. Please take me at my word. says Eric Schlegel from Apple (sorry for citing you Eric, I hope you don't mind it). So, 3rd party Finder CM plug-ins seem to definitely be dead soon and Apple is making it hard again for the small developers who already have such applications developed and are expected to update them for the coming OS release. As it seems at the moment, the only alternative is Service architecture. I also noticed that some Services I set up in Snow Leopard also appear (if applicable) in the Finder contextual menu. Nice, I've got nothing against that, finally I'll be able to move all my code to Cocoa and forget hard-to-swallow CM architecture. There is only one problem though; CM plug-in allows for full dynamism of the menu, while Service architecture doesn't. For example, I provide CM plug-in which can perform a lot of archiving/ compressing/extracting/decompressing tasks on selected files. The menu is usually populated with some static items, which always appear (as implemented in the Services architecture). But I want to display Extract menu item only if at least one of selected files in an archive file. With CM plug-in I can easily examine files in the CMPlugInExamineContext() function call, and depending on their nature provide he Extract menu item, or not. But it is not possible with Services. All menu items are firmly defined in application's Info.plist file. Changing that file dynamically is out of question, since it'd require write access to the application install location and calling NSUpdateDynamicServices() and even if it was feasible, it wouldn't help, since it'd be already too late, the menu needs be modified just before being shown, so the services are already advertised. This long story is just an intro to my real question: will some significant enhancements to the Services architecture that are designed to partially replace the capabilities of contextual menus allow for dynamic modification of the Services menu? If yes, which tool I can use and where to get any documentation to start playing with it so my CM plug-in is ready as a reborn service at the time Snow Leopard is released? If not, what would really be the path to go to implement Finder contextual menu which would be possible to modify on the fly, depending on the current context/selection before showing it to the user? Input Manager? Do I really need to take that direction? Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Dynamic Services menu, CM plug-in alternatives
On sre 01. 07. 2009., at 03:28, Alex Kac wrote: I don't see how Apple makes it difficult. This was a comment about Apple rendering all 3rd party CM plug-ins completely obsolete and useless. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Creating NSAttributedString objects using WebKit in secondary thread
Hello all, Is there any way to initialise and use WebKit out of the main thread? I know this message may look like good candidate for the Webkit-dev mailing list, but I actually don't want to use WebKit directly, it's just a consequence of trying to create NSAttributedString instance from data in memory. Here is the longer story... I need to create NSAttributedString objects and draw them onto the NSImage object (which holds the current graphic context). The attributed strings are created from data in memory buffer and since it is not know at the time of creation what kind of data the buffer holds, I use -[NSAttributedString initWithData:options:documentAttributes:error:] method, which examines the data and loads it using whatever format it seems to contain. Now, according to the documentation: In Mac OS X v10.3, the options key @UseWebKit specifies that WebKit- based HTML importing be used (and must be specified for the other options to be recognised). In Mac OS X v10.4 and later, WebKit is always used for HTML documents, and all of the options except @UseWebKit are recognised (attribute identifiers are available on Mac OS X v10.4 and later; use actual string value keys for Mac OS X v10.3). Since the application in question supports Tiger and above, the WebKit is always used. The problem is that string creation and drawing needs to be executed in the secondary thread and then the WebKit complains whenever the data in the buffer contains a HTML/XML document. Sometimes an exception Cannot use WebKit in secondary thread is thrown, and sometimes only a warning about threading violation is printed out onto the console (with remark that it would be printed only once) and creation of HTML-based attributed strings works, but is very crash-prone. In any case, operation is far from being reliable. Is there any way to solve this without jumping into the main thread for strings creation? Thanks in advance, Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Creating NSAttributedString objects using WebKit in secondary thread
On pon 11. 05. 2009., at 20:07, Douglas Davidson wrote: On May 11, 2009, at 10:53 AM, Dragan Milić wrote: Is there any way to initialise and use WebKit out of the main thread? No, there isn't. This is a fundamental restriction on the use of WebKit. Yes, I know. I just hoped there was some secret magical workaround which would enable me to create attributed strings in the main thread. The point is I'm trying to create something like Finder's Show icon preview functionality, trying to create graphical representations of some text files (which are kept in memory) but to still keep UI responsive if a user wants to scroll view etc. So, I assume creating attributed strings is not thread safe, but I don't remember anything like that stated in the documentation. In my opinion, that looks like a bug. Milke___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Creating NSAttributedString objects using WebKit in secondary thread
On uto 12. 05. 2009., at 00:16, Stephen J. Butler wrote: 2009/5/11 Dragan Milić mi...@mac.com: So, I assume creating attributed strings is not thread safe, but I don't remember anything like that stated in the documentation. In my opinion, that looks like a bug. It is thread safe... if you stick to the Foundation methods. The method you're trying to use, however, is part of the AppKit additions. Hence the non-thread safeness. One way to do this might be to spawn a helper app that accepts data somehow (mach ports might be fastest using vm copy-on-write techniques IIRC, but harder to implement), render on that process's main thread, and then pass the data back (NSAttributedString supports NSCoding). Would I necessarily need another helper app? Can I fork another (child) process and implement server side in it, which would receive raw bytes and return encoded attributed strings, and subsequently implement client side in the parent process (in its secondary thread), which would send raw bytes and receive back encoded attributed strings? Thanks for the hints. Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Creating NSAttributedString objects using WebKit in secondary thread
On uto 12. 05. 2009., at 01:52, Michael Ash wrote: 2009/5/11 Dragan Milić mi...@mac.com: On pon 11. 05. 2009., at 20:07, Douglas Davidson wrote: On May 11, 2009, at 10:53 AM, Dragan Milić wrote: Is there any way to initialise and use WebKit out of the main thread? No, there isn't. This is a fundamental restriction on the use of WebKit. Yes, I know. I just hoped there was some secret magical workaround which would enable me to create attributed strings in the main thread. There's no need for secret magic. Just use performSelectorOnMainThread: to get some code to run on the main thread. Yes I know, I've made an error while typing (was thinking in my native language and translating thoughts to English). That sentence should've read: I just hoped there was some secret magical workaround which would enable me to create attributed strings in the SECONDARY thread. Thanks anyway. Milke___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Creating NSAttributedString objects using WebKit in secondary thread
On uto 12. 05. 2009., at 01:55, Michael Ash wrote: 2009/5/11 Gwynne Raskind gwy...@darkrainfall.org: This is workable, but make sure you use a fork()/exec() pair to re- execute yourself in that case, and use argc/argv in your main() to determine which mode to run in. Don't just use fork() by itself - there are severe limits to what you can do in an only-fork()ed process. What those limits are isn't entirely clear to me; perhaps someone else could elaborate on that? The main problem is that fork() kills all other threads in the child process, leaving you with only the thread that called fork() active. And that effectively invalidates fork()/exec() approach for me, since I cannot afford all other threads being killed. Thanks for clarification. Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Creating NSAttributedString objects using WebKit in secondary thread
On uto 12. 05. 2009., at 06:54, Michael Ash wrote: I think you've misunderstood. There is no problem with the fork/exec approach here. You actually are spot on with that remark, my knowledge of UNIX system calls is not very broad, on the contrary it's rather limited I'd say. Thank you all for the suggestions, I'll definitely investigate (read- try-learn) fork()/exec() route and any eventual question would be off- topic for this list anyway. Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
C: treated as a path component
Hell all, Let's suppose I've got NSString @C:omponent , which represents the name of a file. Is there a way to instruct NSString class not to treat a leading single letter followed by a column as a path separator? Namely, I need this one treated as only one path component @C:omponent, but NSString sees two, @C: and omponent. So, if I ask for the last path component, I get @omponent instead of the whole string @C:omponent. I've searched documentation, took a look into NSPathUtilities.h, but no help. Thanks, Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Paginated PDF from NSView saved in memory
Hello all, Is there any way of saving paginated multipage PDF created with NSPrintOperation into memory? What I need to do is to create multiple PDF out of the NSTextView and put it into the memory buffer. The PDF document should be properly paginated, and NSTextView can hold RTFD attributed string with embedded images, so if there are some images wider then the width of the chosen PDF page, they should be scaled properly to fit. Also, if an image is to be cropped in two subsequent pages, the proper vertical pagination will make sure that it will be drawn on the next page, thus leaving the bottom part of the previous page empty (I hope you get the picture what I'm trying to describe). Using NSPrintOperation in conjunction with NSPrintInfo enables very easy pagination settings with [printInfo setHorizontalPagination:NSFitPagination] and printInfo setVerticalPagination:NSAutoPagination]. But I can's save created PDF into memory, only as a file by setting [[printInfo dictionary] setObject:NSPrintSaveJob forKey:NSPrintJobDisposition] and [[printInfo dictionary] setObject:@path/to/file forKey:NSPrintSavePath]; Using CGContextRef, CGPDFContextCreate(), and drawing cached portion of the NSTextView for the particular page into that CGContextRef between CGPDFContextBeginPage() and CGPDFContextEndPage() creates multipage PDF in memory, but without proper pagination nor cropping and I couldn't find any easy way of doing it. I even read documentation on Core Printing API, hoping it provides saving the print job into the memory, but it seems such functionality doesn't exist. So any ideas? I can get the NSGraphicsContext used by NSPrintOperation. Is there anything I can do with it to capture printed data into memory? Or does anyone know of any easy way of handling pagination (including image resizing) without using NSPrintInfo? Or any other idea? Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Security - Write to protected directory
Hi all. Now, I really sincerely apologise for bringing this thread into life again and for probably abusing the list, since the topic is not strictly Cocoa, so if moderators mind this, just don't approve the message. But I need to ask a bit of advice related to privileged reading/writing and I couldn't find any other place to ask, since it's more related to user experience and app interface design. On pet 03. 10. 2008., at 05:30, Bill Bumgarner wrote: So... again... why does the OP's app need to write anything with authorization privileges (and where)? I'd like to refer to this question... Assume I created an archiving tool and a user wants to extract some files from an archive into a directory one hasn't got write permission for (e.g. /Applictions). Currently, the application shows alert sheet informing the user of permission denied error. But imagine that instead of that, a standard Mac OS X authentication dialog appears, asking for admin password in order to complete the operation (with prior explanation of why that is necessary). Of course, if the user is suspicious, he/she can click Cancel, in which case the permission denied error would appear as intended. Do you think this is a good idea? On the one (positive) side, I think it'd make user interaction much smoother in the situations similar to the one above and possibly look like professional way to handle them. On the other (negative) side, I'm aware many people wouldn't trust giving admin password to my application, some may think that I faked authentication panel, some may wonder why in the world do I need to enter admin password to extract files?!. Also, many people tend to think that password should be asked only by (preferably Apple) installers and system tools (e.g. DiskUtility...) and in no case should it be asked from a shareware app. Once again, I apologise if this was too much of abusing this list. Milke ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
