Re: Menu Item Shortcuts Without Menu Items?
> On Mar 13, 2017, at 17:12, Frank D. Engel, Jr. wrote: > > I need to create the equivalent of a menu item shortcut, but without the menu > item... or, to assign two different shortcuts to the same menu item. > > More precisely: I have a menu item with a shortcut of Command+L. > > I need Command+Shift+L to do exactly the same thing, but it doesn't look > right having two copies of the menu item just to support a second shortcut. > > This needs to work across multiple windows of the application, and there are > enough distinct types that it would be annoying to need to create and > maintain a separate implementation of a solution for each separate window. > > Anyone know how I might be able to pull this off? Neither the NSApplication > nor the NSDocument seem to receive the "performKeyEquivalent:" method, so not > quite sure where to go with this one. > > > Note that I am doing this because of interfacing with an external controller > which, because of the way I am hoping to rig this to behave in a reasonable > way, will sometimes send the keystroke with and sometimes without the shift - > this is an implementation detail that I don't expect the user to be aware of > (if they happen to hold down shift while hitting Command+L... I don't > particularly care - won't really matter :-) Add a second item as an Alternate item and give it command-shift-L. Steve via iPad ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Menu Item Shortcuts Without Menu Items?
On Mar 13, 2017, at 5:12 PM, Frank D. Engel, Jr. wrote: > > I need to create the equivalent of a menu item shortcut, but without the menu > item... or, to assign two different shortcuts to the same menu item. > > More precisely: I have a menu item with a shortcut of Command+L. > > I need Command+Shift+L to do exactly the same thing, but it doesn't look > right having two copies of the menu item just to support a second shortcut. Mark the second menu item as an alternate. That is, set its "alternate" property to true. It will "hide" in the same slot of the menu as the other item and only show when the extra modifier (Shift, in this case) is pressed. Cheers, Ken ___ 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
Menu Item Shortcuts Without Menu Items?
I need to create the equivalent of a menu item shortcut, but without the menu item... or, to assign two different shortcuts to the same menu item. More precisely: I have a menu item with a shortcut of Command+L. I need Command+Shift+L to do exactly the same thing, but it doesn't look right having two copies of the menu item just to support a second shortcut. This needs to work across multiple windows of the application, and there are enough distinct types that it would be annoying to need to create and maintain a separate implementation of a solution for each separate window. Anyone know how I might be able to pull this off? Neither the NSApplication nor the NSDocument seem to receive the "performKeyEquivalent:" method, so not quite sure where to go with this one. Note that I am doing this because of interfacing with an external controller which, because of the way I am hoping to rig this to behave in a reasonable way, will sometimes send the keystroke with and sometimes without the shift - this is an implementation detail that I don't expect the user to be aware of (if they happen to hold down shift while hitting Command+L... I don't particularly care - won't really matter :-) Thank you! ___ 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: Library Location
On Mar 13, 2017, at 13:47 , Richard Charles wrote: > > The location for Xcode project-generated files is specified in the Locations > preference. In this preference "Derived Data:" has a Default value which is > ~/Library/Developer/Xcode/DerivedData. Inside this directory is the following > directory structure. > > ~/Library/Developer/Xcode/DerivedData/Build/Products/Debug > ~/Library/Developer/Xcode/DerivedData/Build/Products/Release > > The final build products for all Xcode projects are located directly inside > these folders. They are not put in subdirectories by project. No, this is not the default preference, although you may have changed it in your Xcode installation. If you click the “Advanced” button, you will a number of sub-options, the first of which (“Unique”) is the factory default. You may have changed this to “Custom”, and thereby forced all project output into the same place. Also, this is the preference for *new* projects. There is also a per-workspace (or “per-project”, if workspaces are hidden) setting on File -> Workspace/Project Settings. If you look there, you’ll see a number of choices, the default one being “Default Location”, meaning what’s in preferences, and if you click the “Advanced” button you’ll all of the same advanced settings, plus the explicit option to use preferences, which is (again) the default. It is, I would say, very unusual and undesirable to dump all project output into the same directories. If I look in my DerivedData folder, I definitely have per-workspace/project subdirectories with long, unique names. If all your projects are being built into the same derived data directories, that would certainly explain some of the behavioral differences you’ve described. “Fixing” that would probably break your current solution, though. ___ 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: Library Location
> On Mar 13, 2017, at 12:26 PM, Quincey Morris > wrote: > > On Mar 13, 2017, at 08:37 , Richard Charles wrote: >> >> By default, Xcode stores derived data for all projects in >> ~/Library/Developer/Xcode/DerivedData. This means that build products for >> all configurations are in the same directory (Debug or Release). > > I don’t understand what/why you’re saying this. Xcode stores derived data for > each project in a separate project-specific subdirectory of DerivedData. It > stores build products for different configurations in different > sub-sub-…sub-directories of the project-specific subdirectory. The location for Xcode project-generated files is specified in the Locations preference. In this preference "Derived Data:" has a Default value which is ~/Library/Developer/Xcode/DerivedData. Inside this directory is the following directory structure. ~/Library/Developer/Xcode/DerivedData/Build/Products/Debug ~/Library/Developer/Xcode/DerivedData/Build/Products/Release The final build products for all Xcode projects are located directly inside these folders. They are not put in subdirectories by project. For the Debug configuration you get just the debug product. For the Release configuration you get the release configuration plus the dSYM file if specified. If you embed a custom library into another project (the main project), when building the main project Xcode will look in these common directories (Debug or Release) for the built configuration product to link against assuming the library *product* file location is specified in main project to be “Relative to Build Products”. A Copy Files Build Phase also needs to be added to the main project to actually embed the library in the app package but it will look here for the proper configuration to embed. In the main project this works great for Run, Test, Profile and Analyze. You just need to remember to build both the debug and release configuration of the library as needed beforehand. It does not work for Archive. It appears that one of reasons it does not work for Archive is because it’s “final” build products are located in a different directory structure somewhere else. However the problem with Archive can be easily solved by folowing the directions previously given. I have been using Xcode for some time in this fashion except that I was specifying the file location of the library *product* in the main project in a very difficult manner using a configuration file and specifying the LIBRARY_SEARCH_PATHS for the debug and release configuration. This worked, but I could never get Archive to work. This new way works much better. Simply select the library *product* in the library project and drag it into the main project. Select the library *product* in the main project and change the Location from "Relative to Group" to "Relative to Build Products” in the file inspector. Run, Test, Profile and Analyze now work as advertised with configurations. When you need to Archive simply follow the directions previously given. This was all inspired by your statement Quincey "Relative to Build Products is the only file referencing method that takes the build configuration into account”. > This suggests that Xcode is finding the built libraries relative to the build > products of the *library* project … No, I don’t think so. >> The only thing that doesn’t work is archiving. Because archiving has a >> different build directory structure you will get a library linker error "No >> such file or directory”. > > It’s possible this is because you never *archived* the library before > archiving the app, so the necessary files were never built. However, even if > you do (or did) archive the library, it may still fail, depending on the > structure of the library archive vs. the subdirectory contents Xcode is > expecting for the app archiving process. No, I tried archiving the library before archiving the app but it did not work. Using the new method I have described, the archive pulls the library built product from the release directory. ~/Library/Developer/Xcode/DerivedData/Build/Products/Release > What matters here is that the derived data is per-workspace, not per-project. > If you open a project and build it, the build products directory is one > subdirectory of DerivedData. If you open a workspace containing the project, > the build products directory is a different subdirectory of DerivedData. Well that is true for some of the data but not all of the data. Final built products are put into a common directory (Debug or Release) for all projects. Workspaces just contain projects so final built products from a workspace are also put here. > The point of all this is that when you have a complex app bundle that > contains components from multiple projects, the correct way to do it is to > use a workspace that contains each of the projects. . . . If I remember correctly, when building, all
Re: Document drafts
Drafts are documents that have been autosaved in a user-visible location (i.e. the app’s iCloud container) and therefore aren’t typical “Untitled” documents from the programmer’s perspective as their fileURL property is not nil. However, they still behave like “Untitled” documents in that they will prompt the user when they close it about whether and where the document should be saved. Contrast this with traditional (non-autosavesInPlace) Untitled document which may autosaved in a non-user-visible location (~/Library/Autosave Information) for which fileURL is still nil, and autosavedContentsFileURL is used instead. -KP > On Mar 12, 2017, at 1:56 PM, Daryle Walker wrote: > > Some of the API for NSDocument is oriented around draft documents. What is a > draft and how does it differ from a non-draft? How do I create/open a > document in draft mode? I didn't see anything about it in the Document guide; > were drafts supposed to be a New World Order like auto-saves or versions, but > got abandoned? > > Sent from my iPhone > ___ > > 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/kperry%40apple.com > > This email sent to kpe...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Printing questions
> On 12 Mar 2017, at 21:23, Daryle Walker wrote: > > > > Sent from my iPhone > >> On Mar 12, 2017, at 5:18 AM, Daryle Walker wrote: >> >> I hope it’s a nice first try, but I have some concerns. >> >> 1. I also added an “Export as PDF…” menu item, which uses the save-as-PDF >> default action. I guess it calls my code, but the docs for >> “NSDocument.pdfPrintOperation” say I should use a separate print-information >> objects for PDF mode. Does the default code take care of that already? Or do >> I have to figure out somehow if I’m in print-to-PDF mode or regular print >> mode and change the initialization of “info” above to be >> “self.pdfPrintOperation” as needed? > > And this is why you shouldn't post half-tired. It's "pdfPrintOperation," not > "pdfPrintInfo," so my override wouldn't be called by definition. I guess I > would override "pdfPrintOperation" to attach a custom print-info, but what > should be in it? Is there some Apple sample code on this property? I didn't > find it at all on GitHub. For NSDocument pdfPrintOperation The docs say : Important This property does not copy the document’s printInfo to the PDF printing operation object. Your app should maintain a separate NSPrintInfo instance specifically for creating PDFs and assign it to the printInfo property of the operation object. So just just set the printInfo on the operation. As to how you configure the printInfo it depends on what output you require - in general its just a bunch of print settings for page size, margins etc. However there are a few save related settings. // flag as a PDF save job [printInfo setJobDisposition:NSPrintSaveJob]; // Set the target destination for the file [printInfoDictionary setObject:pdfInfo.URL forKey:NSPrintJobSavingURL]; Jonathan ___ 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
