Re: Non-deprecated way to determine Process Type (LSUIElement etc.) ?
> On 2015 Nov 26, at 23:33, Ken Thomases wrote: > > Don't use NSRunningApplication when NSApplication will do. Oh, thank you Ken – that’s even better. NSApplication has the same ‘activationPolicy’ property. > The replacement for TransformProcessType() is -[NSApplication > setActivationPolicy:] and has been since 10.6. right under my nose, with a strange name > The method documentation still claims you can't go from regular back to > accessory, but the release notes say you can. Yes, it works. Supposedly since 10.7. Also, in 10.10+, it appears that the number of edge cases wherein you don’t get ownership of the menu bar after activating the first time has been further reduced, so that now this bug only shows when running in Xcode. ___ 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: FSIsAliasFile deprecated - typeOfFile is slow
Although I have experience with your performance hit, one solution I would
probably try when it becomes important again for me would be to do this:
1. Using the BSD layer of APIs, see if the file (alias files are regular files
from a statfs call, even folder aliases) has an extended attribute named
"com.apple.FinderInfo". If it does not, it is not an alias file.
2. If the extended attribute does exist and is of length 32 bytes (or more
although doubtful this would ever change), you might have an alias file. If
less, just say no assuming corruption.
3. Get the bytes of the extended attribute and examine the byte at index 8
(bytes[8]) to see if its high bit is set (bytes[8] | 0x80). If so, you have an
alias; if not, you don't.
4. Add this logic in an appropriate category method (to keep this Cocoa).
For reference, look up ATTR_CMN_FNDRINFO, xattr, Finder.h. Note this extended
attribute has its integers in big-endian format. You might also look at the
fileType parameter of the CoreServices FileInfo that maps the first 16 bytes,
but that requires more checking.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/
> On Nov 27, 2015, at 2:00 PM, Leonardo wrote:
>
> Hi,
> I actually detect whether a file is an alias this way:
> I use a NSString category where self is the filePath.
>
> - (BOOL)IsAliasOld
> {
>FSRefsourceRef;
>
>OSErrerr = [self GetFSRef:&sourceRef];
>if(err) return NO;
>
>BooleanisFSDirectory, aliasFileFlag;
>
>err = FSIsAliasFile(&sourceRef, &aliasFileFlag, &isFSDirectory);
>if(err) return NO;
>else return aliasFileFlag;
> }
>
> - (OSErr)GetFSRef:(FSRef*)sourceRef
> {
>const char *cSrcPath = [[NSFileManager defaultManager]
> fileSystemRepresentationWithPath:self];
>if(cSrcPath == 0 || *cSrcPath == _NUL) return -1;
>
>OSErr err = FSPathMakeRefWithOptions((UInt8*)cSrcPath,
> kFSPathMakeRefDoNotFollowLeafSymlink, sourceRef, NULL);
>return err;
> }
>
>
> Since FSIsAliasFile is deprecated (I compile for 10.9) I would now use
>
> - (BOOL)IsAliasNew
> {
>NSString*type = [[NSWorkspace sharedWorkspace] typeOfFile:self
> error:nil];
>return [type isEqualToString:@"com.apple.alias-file"];
> }
>
> The problem is that the IsAliasNew method is 3.7 times slower than the
> IsAliasOld method. Do you know a way to accomplish that with a faster
> method?
>
___
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: FSIsAliasFile deprecated - typeOfFile is slow
On Nov 27, 2015, at 14:00 , Leonardo wrote: > > The problem is that the IsAliasNew method is 3.7 times slower than the > IsAliasOld method. Do you know a way to accomplish that with a faster > method? It may not be faster but it’s probably more correct to use [NSURL getResourceValue:forKey:error:] or [NSURL resourceValuesForKeys:error:] with the resource key NSURLIsAliasFileKey. ___ 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: FSIsAliasFile deprecated - typeOfFile is slow
On Fri, 27 Nov 2015 23:00:16 +0100, Leonardo said: >The problem is that the IsAliasNew method is 3.7 times slower than the >IsAliasOld method. Do you know a way to accomplish that with a faster >method? Maybe try NSURL's getResourceValue:forKey:error: with NSURLIsAliasFileKey. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
FSIsAliasFile deprecated - typeOfFile is slow
Hi,
I actually detect whether a file is an alias this way:
I use a NSString category where self is the filePath.
- (BOOL)IsAliasOld
{
FSRefsourceRef;
OSErrerr = [self GetFSRef:&sourceRef];
if(err) return NO;
BooleanisFSDirectory, aliasFileFlag;
err = FSIsAliasFile(&sourceRef, &aliasFileFlag, &isFSDirectory);
if(err) return NO;
else return aliasFileFlag;
}
- (OSErr)GetFSRef:(FSRef*)sourceRef
{
const char *cSrcPath = [[NSFileManager defaultManager]
fileSystemRepresentationWithPath:self];
if(cSrcPath == 0 || *cSrcPath == _NUL) return -1;
OSErr err = FSPathMakeRefWithOptions((UInt8*)cSrcPath,
kFSPathMakeRefDoNotFollowLeafSymlink, sourceRef, NULL);
return err;
}
Since FSIsAliasFile is deprecated (I compile for 10.9) I would now use
- (BOOL)IsAliasNew
{
NSString*type = [[NSWorkspace sharedWorkspace] typeOfFile:self
error:nil];
return [type isEqualToString:@"com.apple.alias-file"];
}
The problem is that the IsAliasNew method is 3.7 times slower than the
IsAliasOld method. Do you know a way to accomplish that with a faster
method?
Regards
-- Leonardo
___
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: Caching CIContext?
I can imagine the possibility when the window is in the background with no part
of the window visible that if the system is under memory pressure (System or
GPU) that the backing store might be discarded which would then invalidate your
CIContext.
You could save the pointer to the CGContext at the same time as creating your
CIContext and then in your draw rect you could get the CGContext again using
NSGraphicsContext.currentContext.graphicsPort and see if it is different to the
one saved.
I am not sure that this would be sensible way of keeping track of whether you
need to update your CIContext or not but it might be useful to help work out
what is happening.
If you image view does not resize and is not too large a possible solution
might be to have a bitmap context the size of the image view which is where the
CIContext draws to and then you draw that to the image view. But that might be
slower than just recreating the CIContext each time.
Kevin
> On 27 Nov 2015, at 13:39, thatsanicehatyouh...@me.com wrote:
>
> Hi,
>
> I have an NSImageView with a custom drawing routine. It works as expected
> most of the time, but sometimes the image is not drawn - the reason was not
> obvious. Once when this happened, I opened a popover window and saw that
> image drawn in its background, so it appears I’m doing something incorrect
> with the context.
>
> This view draws a lot, and I heard in a WWDC video that it’s a good idea to
> cache the context as it’s “expensive” to create. It looks roughly like this:
>
> - (CIContext*)ciContext
> {
>if (_ciContext == nil) {
>CGContextRef cgContext;
>if (floor(NSAppKitVersionNumber) < NSAppKitVersionNumber10_10) {
>// anything up to 10.9.x
>cgContext = NSGraphicsContext.currentContext.graphicsPort;
>} else {
>// 10.10 or higher
>cgContext = NSGraphicsContext.currentContext.CGContext;
>}
>
># create context
>_ciContext = [CIContext contextWithCGContext:cgContext ...
>}
>return _ciContext;
> }
>
> In drawRect:, I use CoreImage to create a CIImage, draw it, then draw an
> overlay on top of that:
>
> - (void)drawRect:(NSRect)dirtyRect
> {
>// ... build image, then draw:
>[self.ciContext drawImage:image inRect:inRect fromRect:image.extent];
>
>// draw overlay, obtaining the CGContextRef the same way as in the
> CIContext above.
> }
>
> Another data point: the image overlay is *always* drawn; the CIImage
> sometimes is not.
>
> Is it appropriate to cache a CIContext in this way? It feels like I’m missing
> a lock/unlock, store/restore, or losing the context somewhere, but I’m not
> sure exactly the correct approach.
>
> Thanks!
>
> Demitri
>
>
>
> ___
>
> 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/ktam%40yvs.eu.com
>
> This email sent to k...@yvs.eu.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
Caching CIContext?
Hi,
I have an NSImageView with a custom drawing routine. It works as expected most
of the time, but sometimes the image is not drawn - the reason was not obvious.
Once when this happened, I opened a popover window and saw that image drawn in
its background, so it appears I’m doing something incorrect with the context.
This view draws a lot, and I heard in a WWDC video that it’s a good idea to
cache the context as it’s “expensive” to create. It looks roughly like this:
- (CIContext*)ciContext
{
if (_ciContext == nil) {
CGContextRef cgContext;
if (floor(NSAppKitVersionNumber) < NSAppKitVersionNumber10_10) {
// anything up to 10.9.x
cgContext = NSGraphicsContext.currentContext.graphicsPort;
} else {
// 10.10 or higher
cgContext = NSGraphicsContext.currentContext.CGContext;
}
# create context
_ciContext = [CIContext contextWithCGContext:cgContext ...
}
return _ciContext;
}
In drawRect:, I use CoreImage to create a CIImage, draw it, then draw an
overlay on top of that:
- (void)drawRect:(NSRect)dirtyRect
{
// ... build image, then draw:
[self.ciContext drawImage:image inRect:inRect fromRect:image.extent];
// draw overlay, obtaining the CGContextRef the same way as in the
CIContext above.
}
Another data point: the image overlay is *always* drawn; the CIImage sometimes
is not.
Is it appropriate to cache a CIContext in this way? It feels like I’m missing a
lock/unlock, store/restore, or losing the context somewhere, but I’m not sure
exactly the correct approach.
Thanks!
Demitri
___
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: Bunch of CoreData based NSDocument questions.
On Nov 26, 2015, at 22:41 , Motti Shneor wrote: > > So -- I MUST warn him and allow him to cancel this quit command. > unfortunately, the @$@$@ NSDocument architecture insists I'm not to be > involved, and shortcuts even the ApplicationDelegate > "applicationShouldTerminate" for me, happily autosaving what's dirty, and > quitting immediately. I’ve been looking into this a bit, and the situation is a bit more complicated than I thought. On re-reading the documentation, I see that the default for NSSupportsSuddenTermination is NO, so this issue is NOT caused by sudden termination. With autosavesInPlace==YES, you *do* have an opportunity to cancel app termination when there are dirty documents. I’ve just tried this in a brand new project, and it works fine. I suspect that you implemented the delegate method with the wrong signature (it has one parameter), but if not I can’t explain why the delegate method wasn’t called when you tried it. However, there is some NSDocument behavior that’s affected by the app trying to quit (i.e. terminate: being called), but not affected by whether the app actually quits. Specifically, when the app tries to quit, with autosavesInPlace==YES, the NSDocument machinery is *first* informed that the app wants to quit. At this point, it autosaves all documents, then discards all document windows and the document object itself. This is semantically *not* a close, either of the windows or the document, so none of the close machinery is invoked. This probably will surprise you, but I guess the point is that autosavesInPlace==YES *implies* that the document and its windows are restorable, and you don’t get any control over that. By the time your delegate method is called, it’s too late to prevent the document being discarded. The news isn’t completely bad, though. If a previous-saved document is discarded in this way, you can get the document back by just opening it again — it will come back still dirty, if it was before. If your app doesn’t discard the microscope state when a document disappears (which it might already, or it sounds like it could if it wanted to), then reopening the document should get the user back to where he was. In this scenario, you would discard the microscope state when the document *closes* through the regular close machinery. There are two problems with all this: 1. If the document has never been saved (is untitled), if you try to quit the app, the autosaved untitled document is written to disk, but the only way to get it back again (AFAICT) is to really quit the app and re-launch it. That means of course losing the microscope state. You might be able to mitigate this by forcing an immediate save when a new document is created, so the user never sees any untitled documents. 2. Because you’re using XXPersistentDocument, autosaving is going to be slow. I don’t see any direct solution to this, because autosavesInPlace==YES autosaving just wasn’t designed for a document based on a database. If you were using your own database directly, you could possibly arrange to do something with checkpoints or rollbacks, but I think you’re out of luck when using Core Data with the NSDocument architecture. I still think you’d be better off to look for a way to have documents that contain something like a delta to the database. Separately, you would have non-document state that kept track of the hardware state, as long as the app was running. Then, autosaving or saving the document would write the delta to disk, and closing (or discarding) the document would be recoverable. The only check you’d have to make when the document was re-opened is that the hardware state hasn’t changed since the last autosave/save. (Presumably you have some way to know when the hardware state changes, otherwise you wouldn’t be able to deal with the case where someone changes the microscope setup while a document is open and active.) I’m sure what I’m suggesting won’t actually work for you in detail, because I’m sure the details of what you’re doing are more complicated and/or more constrained. But I really don’t see a solution to your autosave/save performance issue without some way around copying the database. HTH ___ 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
