Re: drawRect runs twice, bounds are changed in between
Would the Managing Live Resize methods of NSView
(https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/#//apple_ref/doc/uid/2014-SW41)
be helpful?
The docs for -viewWillStartLiveResize suggest that that would be a good place
to prepare for a resize instead of trying to manage how has the size changed
decisions in -drawRect:.
On Jan 14, 2015, at 8:39 PM, N!K pu56ucl...@alumni.purdue.edu wrote:
On Jan 13, 2015, at 10:50 PM, Jens Alfke j...@mooseyard.com wrote:
On Jan 13, 2015, at 9:25 PM, N!K pu56ucl...@alumni.purdue.edu wrote:
A breakpoint at the end of drawRect shows that it runs twice. After the
second pass, the view appears, as it should.
Between passes, bounds is changed somehow, as shown by NSLog at the start
and end of drawRect.
Since this will upset code that I will add later, I’d like to stop this.
The view's being resized, probably as part of view layout. Ideally AppKit
shouldn't draw the view before it gets to its final size, but maybe this is
part of an animation, or maybe it's something that hasn't been optimized
100% in AppKit.
In general, you should not make assumptions about when and how often
-drawRect: will be called. That's up to AppKit. Your job is just to draw the
view when you’re told to.
OK. Cause is unknown (probably unknowable?) but part of Cocoa. Just because
there was only one pass in other projects, I can’t depend on it. drawRect can
happen anytime.
You haven't said why the bounds change will upset your code; is the view
being changed to the wrong size? That would be an actual problem, but it
isn't related to being drawn multiple times. You'd need to look at the view
constraints in your window to diagnose that.
—Jens
“Why” takes a little explaining. Thank you for your patience.
I’m trying to learn more about drawing. One stumbling block was getting an
NSBezierPath to change size proportional to the window size when the corner
is dragged. Per Graham Cox’s suggestion, the view size change can be detected
in subsequent passes of drawRect by comparing
ratioX = NSWidth ([_path bounds])/NSWidth(bounds);
ratioY = NSHeight([_path bounds])/NSHeight(bounds);
with their initial values, which were established in the one pass of drawRect
before the view appeared.
This worked perfectly. I used the ratios in
-(void)resize{
scaleX = ratioX0/ratioX;
scaleY = ratioY0/ratioY;
NSAffineTransform* tfm = [[NSAffineTransform alloc] init];
[tfm scaleXBy:scaleX yBy:scaleY];
temp = [tfm transformBezierPath:_path];
}
The initial view was correct. Then dragging the window corner induced
drawRect’s, which detected the changes and scaled the original _path each
time; no cumulative errors. The path size tracked the view size correctly.
Next I wanted to learn how to scale the whole view in a new project, not just
the NSBezierPath. I was planning to later include other objects with the
NSBezierPath and wanted them to be scaled, too. I used the same
initialization and failed because of the bounds change between two passes,
which I failed to anticipate. The first pass set the initial values. The
second pass detected the change and scaled the view before the view appeared.
-(void)resize{
scaleX = ratioX0/ratioX;
scaleY = ratioY0/ratioY;
NSAffineTransform* tfm = [[NSAffineTransform alloc] init];
[tfm scaleXBy:scaleX yBy:scaleY];
temp = [tfm transformBezierPath:_path];
}
Thus the path in the initial view was quite different from the initial path,
and dragging the corner of the window caused wildly incorrect scaling.
My hope was that there might be a way of suppressing the second pass before
display of the view. Now I know better and will figure out another way to
initialize and track. Thank you for correcting me.
Nick
___
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: Search for emails in Mail’s previous recipients list from MacOSX app
On 15/01/15 22:04, Steffen Andersen wrote: I am currently working on a MacOSX app, where the user will be able to send mails generated based on different user input. To help the user, when writing an email address, it would be great, if it was possible to search in the previous recipients list/db Mail uses. As not all emails will be in the users Contacts. From a bit of search I’ve located the previous recipients list/db ~/Library/Containers/com.apple.corerecents.recentsd/Data/Library/Recents/Recents and it seems to be a sqlite. Is there any issues accesses it from with in an app, if I want to launch the app to AppStore? You can't access such data (data in containers of other apps, or data in the general Library folder) in sandboxed apps. Apps on the Mac App Store need to be sandboxed. There are only a handful of paths you can access with the appropriate entitlements in place (pictures, downloads, music, movies). Other paths require explicit user consent and the only way to get that is having the user point to the path in an open/save sheet/panel. Regards Markus -- __ Markus Spoettl ___ 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: drawRect runs twice, bounds are changed in between
On 15 Jan 2015, at 3:39 pm, N!K pu56ucl...@alumni.purdue.edu wrote: I’m trying to learn more about drawing. One stumbling block was getting an NSBezierPath to change size proportional to the window size when the corner is dragged. Per Graham Cox’s suggestion, the view size change can be detected in subsequent passes of drawRect by comparing ratioX = NSWidth ([_path bounds])/NSWidth(bounds); ratioY = NSHeight([_path bounds])/NSHeight(bounds); with their initial values, which were established in the one pass of drawRect before the view appeared. This wasn't my suggestion, exactly. Don't use -drawRect to establish anything - just use it to draw. Only draw. Only ever draw. My actual suggestion was to create your bezier path at some known size - I've used a size of 1 x 1 centred at 0,0 for example, then scale it to your needs *WHEN* you draw it, then discard the scaled version. That way you are proof against whatever size your view is, and when and how often it's called. You don't (and shouldn't) need a -resize method because you never store the results of it anyway. All that said, this is just toy code that shows you how you can apply scaling to a path - it isn't necessarily much use in real-world app. One problem with it for example is that it's possible to end up (if your view is zero-sized, as it can be when initialized) with div-by-zero errors that end up putting NaNs into the path's coordinates. Core Graphics (which has always tolerated that sort of thing historically) will, since 10.9, throw a fit and summarily abort your app. If you want to allow your view to zoom, rather than just display some content scaled, look into the relationship between the bounds and the frame of the view. Setting these different will cause zooming. If you want a slghtly more realistic way to place bezier path objects in a view, one approach could be to create an object that has a bezier path (maybe at a fixed size, such as 1 x 1), and also other states of it, such as its drawn size, angle and position from which you can create a transform. It's also convenient to include things such as stroke and fill colours. --Graham ___ 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
Search for emails in Mail’s previous recipients list from MacOSX app
Hi I am currently working on a MacOSX app, where the user will be able to send mails generated based on different user input. To help the user, when writing an email address, it would be great, if it was possible to search in the previous recipients list/db Mail uses. As not all emails will be in the users Contacts. From a bit of search I’ve located the previous recipients list/db ~/Library/Containers/com.apple.corerecents.recentsd/Data/Library/Recents/Recents and it seems to be a sqlite. Is there any issues accesses it from with in an app, if I want to launch the app to AppStore? I’ve not been able to find any documentation on how to access it with an Cocoa API. Kind regards Steffen Andersen — Sent from Mailbox ___ 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
Directory navigated to by menu File Open
I have noticed that the directory which is navigated to in the File Open dialog of my NSDocument-based application does not give what I expect, and am trying to control it. To make sure it’s not due to something I did, I am experimenting with Apple’s TextEdit sample project instead. Although the expected directory is not mentioned in the documentation of -[NSDocumentController openDocument:], -[NSDocumentController currentDirectory] is said to return “the directory path to be used as the starting point in the Open panel”. Furthermore, Apple’s implementation returns “the first valid directory from the following list: • The directory location where the current document was last saved • The last directory visited in the Open panel • The user’s home directory So, great, I thought, just override -currentDirectory in the NSDocumentController subclass for TextEdit, and I can make it go wherever I want to. But, no. Although my -currentDirectory override is invoked when I click menu File Open, any path I return seems to be ignored. If no document is open (no “current document”), it seems to always somehow remember and go to the directory of the last document that was opened, even if this was in a long-app application run. This is the case even if I delete the “recents” file ~/Library/Preferences/com.apple.TextEdit.LSSharedFileList.plist before launching. And no such path is shown when I run the command “defaults com.appleTextEdit”. The system must be remembering this path elsewhere. Presumably I could get the control I want by overriding and re-implementing -openDocument: to actually use -currentDirectory the way the documentation says it should. It should be a lot less lines of code than I’ve written in this message. But before I do that I’m asking if anyone else has been here and done anything similar. ___ 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: Directory navigated to by menu File Open
On Jan 15, 2015, at 6:16 PM, Jerry Krinock je...@ieee.org wrote: I have noticed that the directory which is navigated to in the File Open dialog of my NSDocument-based application does not give what I expect, and am trying to control it. So, great, I thought, just override -currentDirectory in the NSDocumentController subclass for TextEdit, and I can make it go wherever I want to. But, no. Although my -currentDirectory override is invoked when I click menu File Open, any path I return seems to be ignored. That's unfortunate. It definitely seems like that should have worked. If no document is open (no “current document”), it seems to always somehow remember and go to the directory of the last document that was opened, even if this was in a long-app application run. This is the case even if I delete the “recents” file ~/Library/Preferences/com.apple.TextEdit.LSSharedFileList.plist before launching. And no such path is shown when I run the command “defaults com.appleTextEdit”. The system must be remembering this path elsewhere. On my 10.9.5 system, the last location is remembered in the defaults for TextEdit. The command defaults read com.apple.TextEdit NSNavLastRootDirectory provides it. Presumably I could get the control I want by overriding and re-implementing -openDocument: to actually use -currentDirectory the way the documentation says it should. It should be a lot less lines of code than I’ve written in this message. But before I do that I’m asking if anyone else has been here and done anything similar. I think you should override -runModalOpenPanel:forTypes: and -beginOpenPanel:forTypes:completionHandler:. In each, you would customize the Open panel by setting the directoryURL property and then call through to super. Regards, 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
Re: Directory navigated to by menu File Open
On Jan 15, 2015, at 4:34 PM, Ken Thomases k...@codeweavers.com wrote: On Jan 15, 2015, at 6:16 PM, Jerry Krinock je...@ieee.org wrote: I have noticed that the directory which is navigated to in the File Open dialog of my NSDocument-based application does not give what I expect, and am trying to control it. So, great, I thought, just override -currentDirectory in the NSDocumentController subclass for TextEdit, and I can make it go wherever I want to. But, no. Although my -currentDirectory override is invoked when I click menu File Open, any path I return seems to be ignored. That's unfortunate. It definitely seems like that should have worked. If no document is open (no “current document”), it seems to always somehow remember and go to the directory of the last document that was opened, even if this was in a long-app application run. This is the case even if I delete the “recents” file ~/Library/Preferences/com.apple.TextEdit.LSSharedFileList.plist before launching. And no such path is shown when I run the command “defaults com.appleTextEdit”. The system must be remembering this path elsewhere. On my 10.9.5 system, the last location is remembered in the defaults for TextEdit. The command defaults read com.apple.TextEdit NSNavLastRootDirectory provides it. defaults read your.app.here NSNavLastRootDirectory will provide it for your app too; our code comment indicates we were told this at some long-past WWDC. ___ 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: Directory navigated to by menu File Open
On Jan 15, 2015, at 16:16 , Jerry Krinock je...@ieee.org wrote: Presumably I could get the control I want by overriding and re-implementing -openDocument: to actually use -currentDirectory the way the documentation says it should. I’m not entirely sure you should do that, at least not casually. Note that ‘currentDirectory’ has been available since OS X 10.0, and that methods that displayed open panels with a directory parameter (such as ‘beginForDirectory:…’, thereby “encouraging” you to set the directory yourself) were *discarded* in 10.6. So, I’m guessing that in 10.6, a new layer of UI behavior was overlaid on top of what happened before, that’s supposed to remember what the user did before. (In a sense, this might have been Apple's response to the 3rd party Default Folder and SuperBoomerang extensions of the olden days, which had been kicking Navigation Services’ butt for decades.) In effect, ‘currentDirectory’ died in 10.6. It’s possible that some or all of the old behavior is used when the defaults that Ken and Lee Ann mentioned have not yet been set (that is, the first time the app is used after installation), which might explain why ‘currentDirectory’ is not deprecated. It’s also possible that Apple realized that its new “behavior overlay” approach isn’t good for certain classes of app, so left it open to you to make it behave the old way using the technique that Ken described (setting the directory after creating the open panel) — or, really, allowing you to make it behave in an ol’ non-standard way, should you choose. If that’s all true, then you should pause before jumping in and interfering. If it’s just a matter of your (historical) expectations, you’re probably better off leaving it as it is, so that it’s consistent with what other apps do — and what Mac users younger than us (ahem!) unconsciously expect. Only if it actively interferes with the way your users actually use your app (and they’re complaining about it) could I see an unarguable reason for going your own way on this. FWIW ___ 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: Directory navigated to by menu File Open
On 2015/01/16, at 11:24, Quincey Morris quinceymor...@rivergatesoftware.com wrote: Only if it actively interferes with the way your users actually use your app (and they’re complaining about it) could I see an unarguable reason for going your own way on this. I can see a lot of reasons a particular NSDocument subclass might always go to an app-specified directory. Not the common standard use case but specialized ones. You might have a directory for templates or scripts specific to your app, but for customizable files, and it might be in the Application Support folder (or a sub folder) for the app. In that sort of context you need a specific behavior. Another possibility is a network location. Yet another might be a secured location that is inside a dmg or something that requires authentication first. ___ 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
NSSearchField appearance in toolbar
Hi, My app has a bottom bar with several buttons and a search field. My problem is I cannot get the search field to have the same appearance as when it’s in an NSToolbar like Finder or Mail.app. But the buttons in my bottom bar do have the appearance as if they were in a toolbar. How can I get my search field to have the “toolbar appearance” when it’s not in a real toolbar? rc ___ 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
