Re: Weird NSPredicate structure when using "first" in keypath

[Jens Alfke]

> On Jan 9, 2017, at 6:38 PM, Aaron Tuller  wrote:
> 
> Try doing
> name.#first
> as FIRST and LAST are reserved words and need escaping:

Thanks for the answer. Unfortunately this is a library that will allow 
developers to provide their own predicate strings, and I can imagine this 
causing confusion (and therefore support requests for us.)

I added a workaround to my code that will recognize the weird predicates formed 
by using unescaped ‘first’ and ‘last’, and handle them appropriately. I hope 
that’ll be robust enough!

—Jens
___

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: Weird NSPredicate structure when using "first" in keypath

[Aaron Tuller]

Try doing

name.#first

as FIRST and LAST are reserved words and need escaping:

https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html

I just tried:

NSComparisonPredicate *p = (NSComparisonPredicate 
*)[NSComparisonPredicate predicateWithFormat:@"name.#first == 'Aaron'"];

NSDictionary *myself = @{@"name": @{@"first" : @"Aaron", 
@"last" : @"Tuller"}};
NSDictionary *yourself = @{@"name": @{@"first" : @"Jens", 
@"last" : @"Alfke"}};

NSLog(@"%i", [p evaluateWithObject:myself]);
NSLog(@"%i", [p evaluateWithObject:yourself]);

works as expected.

-aaron


> On Jan 9, 2017, at 6:01 PM, Jens Alfke  wrote:
> 
> I’m writing code that walks through an NSPredicate and generates an alternate 
> form of query from it (similar to what CoreData and Realm do.)
> 
> I’m seeing some very weird undocumented behavior when format strings are 
> compiled into NSPredicates, if the format string includes a key-path with a 
> property named “first” or “last”. The resulting predicate contains an 
> NSExpression of an undocumented type.
> 
> - For example, “name.middle == ‘Bob’” compiles to what you’d expect; the LHS 
> of the ‘equals’ predicate is an expression of NSKeyPathExpressionType, with 
> key-path “name.middle”.
> - But “name.first == ‘Bob’” results in an LHS that’s of 
> NSFunctionExpressionType, with a function selector “valueForKeyPath:”, and 
> even weirder, the expression’s argument is an expression with the 
> undocumented expressionType 11. I don’t know what that is supposed to mean, 
> except that its -description is “FIRST” (all caps).
> 
> NSComparisonPredicate
>   predicateOperatorType = NSEqualToPredicateOperatorType
>   leftExpression =
>   NSKeyPathExpression
>   expressionType = NSFunctionExpressionType
>   function = “valueForKeyPath:”
>   operand =
>   NSKeyPathExpression
>   expressionType = NSKeyPathExpressionType
>   keyPath = “name”
>   operand = SELF
>   arguments = [
>   NSSymbolicExpression
>   expressionType = 11 (?)
>   ]
>   rightExpression =
>   NSExpression
>   expressionType = NSConstantValueExpressionType
>   constantValue = @“Bob” 
> 
> Is there something magic about the property name “first”? The only related 
> thing I’ve seen is that in predicate syntax arrays can be indexed with 
> “[FIRST]” or “[LAST]”, but that’s in an array subscript not a keypath…
> 
> —Jens
> ___
> 
> 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/mandelbaum%40mac.com
> 
> This email sent to mandelb...@mac.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

Weird NSPredicate structure when using "first" in keypath

[Jens Alfke]

I’m writing code that walks through an NSPredicate and generates an alternate 
form of query from it (similar to what CoreData and Realm do.)

I’m seeing some very weird undocumented behavior when format strings are 
compiled into NSPredicates, if the format string includes a key-path with a 
property named “first” or “last”. The resulting predicate contains an 
NSExpression of an undocumented type.

- For example, “name.middle == ‘Bob’” compiles to what you’d expect; the LHS of 
the ‘equals’ predicate is an expression of NSKeyPathExpressionType, with 
key-path “name.middle”.
- But “name.first == ‘Bob’” results in an LHS that’s of 
NSFunctionExpressionType, with a function selector “valueForKeyPath:”, and even 
weirder, the expression’s argument is an expression with the undocumented 
expressionType 11. I don’t know what that is supposed to mean, except that its 
-description is “FIRST” (all caps).

NSComparisonPredicate
predicateOperatorType = NSEqualToPredicateOperatorType
leftExpression =
NSKeyPathExpression
expressionType = NSFunctionExpressionType
function = “valueForKeyPath:”
operand =
NSKeyPathExpression
expressionType = NSKeyPathExpressionType
keyPath = “name”
operand = SELF
arguments = [
NSSymbolicExpression
expressionType = 11 (?)
]
rightExpression =
NSExpression
expressionType = NSConstantValueExpressionType
constantValue = @“Bob” 

Is there something magic about the property name “first”? The only related 
thing I’ve seen is that in predicate syntax arrays can be indexed with 
“[FIRST]” or “[LAST]”, but that’s in an array subscript not a keypath…

—Jens
___

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: Manually building GUI and Retina Macs

[Andreas Falkenhahn]

Thanks for the information!

On 09.01.2017 at 17:33 Ken Thomases wrote:

> On Jan 9, 2017, at 10:13 AM, Andreas Falkenhahn  
> wrote:



> I'm building some windows and controls in my app by manually
> creating NSWindow objects and the respective controls and then
> adding them to the NSWindow by using

>[[win contentView] addSubview:control];

> The control and window sizes and their positions are all hard-coded
> in pixels.



> You may have thought they were specified in pixels, but that's not
> correct.  All of the APIs for sizing windows, views, controls, etc.
> take sizes and positions in "points".  These are NOT typographic
> points (~1/72") which you may be familiar with.  These are an
> abstract unit not necessarily related to real-world dimensions (such as 
> inches) nor pixels.


> You can think of the size of a point as being chosen by the user
> (indirectly via System Preferences > Displays) such that 12-point
> text is comfortable to read at the typical screen distance.

>  Thus, it is assumed that the UI font size stays the
> same. 




> Fonts are measured in the same point coordinate system, so that's
> kind of reasonable to assume _except_ that Apple has changed the
> system UI font on repeated occasions.  They try to keep the metrics
> pretty close, but it's just not possible to keep it exact, given their goals 
> in changing the font.

> Now I was wondering how such code will behave on Retina Macs?
> Will it mess up completely because I use hard-coded position
> and size values but the font on Retina Mac is bigger?



> Because you work in abstract points, there's no problem with Retina
> displays.  Your windows, views, controls, etc. will remain at a
> comfortable/sensible size, they'll just have finer detail.  The main
> area of concern is bitmap images.  If you don't provide @2x versions
> of your images, they may get scaled up in terms of pixels to
> maintain their size in points.  That will result in chunky images.

>  I don't
> have a Retina Mac here so can somebody explain (or point me to
> some documents) how to write code that scales nicely on Retina
> Macs?




> https://developer.apple.com/high-resolution/
> https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html




> I'm familiar with Retina development on iOS. On iOS, position and
> size on Retina and Non-Retina devices are basically the same.
> To solve the problem of higher resolutions, there is a scale
> coefficient that can be queried by looking into "UIScreen.scale".
> This way apps written for non-Retina devices normally just work
> on Retina devices. Do Retina Macs use a similar implementation?




> More or less, yes.

> Is there any way to test if my app runs nicely on a Retina Mac
> without actually having a Retina Mac?


> Yes, you can use Quartz Debug to enable high-resolution display
> modes.  These basically cause Cocoa to see your screen as half its
> normal dimensions (in terms of points).  So, your app will display
> visually huge but with the finer detail that Retina enables.  You
> should just imagine that your screen is a small Retina display that you're 
> standing too close to. ;)
> https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Testing/Testing.html#//apple_ref/doc/uid/TP40012302-CH6-SW2

> Regards,
> Ken

>  


-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.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: Manually building GUI and Retina Macs

[Ken Thomases]

On Jan 9, 2017, at 10:13 AM, Andreas Falkenhahn  wrote:
> 
> I'm building some windows and controls in my app by manually
> creating NSWindow objects and the respective controls and then
> adding them to the NSWindow by using
> 
>   [[win contentView] addSubview:control];
> 
> The control and window sizes and their positions are all hard-coded
> in pixels.

You may have thought they were specified in pixels, but that's not correct.  
All of the APIs for sizing windows, views, controls, etc. take sizes and 
positions in "points".  These are NOT typographic points (~1/72") which you may 
be familiar with.  These are an abstract unit not necessarily related to 
real-world dimensions (such as inches) nor pixels.

You can think of the size of a point as being chosen by the user (indirectly 
via System Preferences > Displays) such that 12-point text is comfortable to 
read at the typical screen distance.

> Thus, it is assumed that the UI font size stays the
> same. 

Fonts are measured in the same point coordinate system, so that's kind of 
reasonable to assume _except_ that Apple has changed the system UI font on 
repeated occasions.  They try to keep the metrics pretty close, but it's just 
not possible to keep it exact, given their goals in changing the font.

> Now I was wondering how such code will behave on Retina Macs?
> Will it mess up completely because I use hard-coded position
> and size values but the font on Retina Mac is bigger?

Because you work in abstract points, there's no problem with Retina displays.  
Your windows, views, controls, etc. will remain at a comfortable/sensible size, 
they'll just have finer detail.  The main area of concern is bitmap images.  If 
you don't provide @2x versions of your images, they may get scaled up in terms 
of pixels to maintain their size in points.  That will result in chunky images.

> I don't
> have a Retina Mac here so can somebody explain (or point me to
> some documents) how to write code that scales nicely on Retina
> Macs?

https://developer.apple.com/high-resolution/ 

https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html
 



> I'm familiar with Retina development on iOS. On iOS, position and
> size on Retina and Non-Retina devices are basically the same.
> To solve the problem of higher resolutions, there is a scale
> coefficient that can be queried by looking into "UIScreen.scale".
> This way apps written for non-Retina devices normally just work
> on Retina devices. Do Retina Macs use a similar implementation?

More or less, yes.

> Is there any way to test if my app runs nicely on a Retina Mac
> without actually having a Retina Mac?

Yes, you can use Quartz Debug to enable high-resolution display modes.  These 
basically cause Cocoa to see your screen as half its normal dimensions (in 
terms of points).  So, your app will display visually huge but with the finer 
detail that Retina enables.  You should just imagine that your screen is a 
small Retina display that you're standing too close to. ;)
https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Testing/Testing.html#//apple_ref/doc/uid/TP40012302-CH6-SW2
 


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

Manually building GUI and Retina Macs

[Andreas Falkenhahn]

I'm building some windows and controls in my app by manually
creating NSWindow objects and the respective controls and then
adding them to the NSWindow by using

   [[win contentView] addSubview:control];

The control and window sizes and their positions are all hard-coded
in pixels. Thus, it is assumed that the UI font size stays the
same. 

Now I was wondering how such code will behave on Retina Macs?
Will it mess up completely because I use hard-coded position
and size values but the font on Retina Mac is bigger? I don't
have a Retina Mac here so can somebody explain (or point me to
some documents) how to write code that scales nicely on Retina
Macs?

I'm familiar with Retina development on iOS. On iOS, position and
size on Retina and Non-Retina devices are basically the same.
To solve the problem of higher resolutions, there is a scale
coefficient that can be queried by looking into "UIScreen.scale".
This way apps written for non-Retina devices normally just work
on Retina devices. Do Retina Macs use a similar implementation?

Is there any way to test if my app runs nicely on a Retina Mac
without actually having a Retina Mac?

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.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: AVSimplePlayer in Swift?

[Charles Jenkins]

I will post code later today. In the meantime, I think I know what’s
happening, but not yet why. In short, the IB message is worthless, and KVO
is actually working. Ironically, proved that to myself by ditching it
altogether and switching currentTime back to using a local (non-computed)
property and didSet, but this time, in didSet I imitated the code in the
ObjC setCurrentTime() a little more closely.

What I found is if I comment out my call to player.seek(), the video plays
through and all the controls work (except of course no scrubbing). The
count of seconds reported by the periodic time observer (hereafter, PTO)
always increases.

But if I uncomment the player.seek() line, the video seems to be frozen on
the first frame and all the PTO requests are to seek back to 0.0.

I think what happens is, the video actually is playing, but the PTO checks
when it’s at 0.0, the player internally moves on, and then my KVO or didSet
requests a seek back to 0.0. And the process repeats ad infinitum. The PTO
is always a tiny bit behind where the video actually is, so it just keeps
requesting seeks backward.

It appears that if my setter for currentTime does the same thing as the
ObjC one, I’m toast.


On Sun, Jan 8, 2017 at 5:13 PM, Charles Srstka 
wrote:

> On Jan 8, 2017, at 1:12 PM, Quincey Morris  rivergatesoftware.com> wrote:
>
>
> On Jan 8, 2017, at 05:49 , Charles Jenkins  wrote:
>
>
> changing to CDouble didn’t help
>
>
> This is one of those cases where I regretted pressing “Send” just 2
> minutes later. What I wrote was a thought process that didn’t make complete
> sense.
>
> There are 4 possibilities and you’ll need to narrow it down to one:
>
> 1. The property type is incorrect. You could try changing it to an
> explicit NSNumber, which is the type that the binding actually requires.
>
>
> This is not the problem; KVO works just fine with a property typed as
> Double as long as the property is marked ‘dynamic', which my sample code
> demonstrates (for some reason, the mailing list software separated the
> “.zip” from the rest of the link, so just add “.zip” to the end manually to
> download it).
>
> 2. The property accessors are not using the correct calling convention
> (@objc). If they’re in a view controller subclass (which is an @objc)
> object, they’ll normally be @objc, but there are some situations (e.g.
> declaring them private) that may make them native Swift. Leaving off the
> “dynamic” would come under this case too, but this was covered already.
>
>
> 3. The property declaration is fine, but IB is broken and doesn’t
> recognize the property as compatible. It may simply fail to set up the
> binding properly, even though it would work if it did. You could try
> leaving it unbound, and set up the binding at run time.
>
> 4. The property is fine, and something else is wrong.
>
> Finally, I’d note that the discussion in this thread had jumped back and
> forth between bindings and KVO. I’ve lost track of whether you’re saying
> that KVO isn’t working here (Charles posted sample code that he said
> works), or whether bindings aren’t working here.
>
>
> I think that seeing a simplified version of the code that isn’t working
> would be the easiest way to debug this at this point. OP, would you mind
> posting it?
>
> Charles
>
>


-- 

Charles
___

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

Is SMJobBless still the correct way to do authorisation?

[John Brownie]

I'm working on an app which will be written in Swift, but which needs to 
use some authorisation method to allow creation and deletion of files 
and folders inside the /Library directory. Last time I needed this sort 
of ability (three years ago), I took the SMJobBless sample code, along 
with Even Better Authorization Sample, to create a fairly complex 
system, which I no longer understand at any depth.


Before diving back into all this, am I going in the right direction? Can 
I get away with a simpler system just using SMJobBless as a basis? Is 
there better sample code out there that I can learn from? How will 
mixing Objective-C in the helper application and Swift in the main 
application work in practice?


Any other advice?

Thanks,
John
--
John Brownie
In Finland on furlough from SIL Papua New Guinea
___

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