Date   

Re: Mysterious build warning with .xib file

Quincey Morris
 

On Nov 5, 2019, at 20:30 , Graham Cox <graham@...> wrote:

Hmmm, oh well, I guess I’ll just live with it. Bigger fish to fry and all that.

I played with this a bit more. It turns out that the bug is “transient”, in the sense that if you quit Xcode and relaunch, it picks up the correct deployment target.


Re: NSDraggingSession distorts the images I give it

Jon Gotow
 

On Nov 6, 2019, at 2:42 AM, Graham Cox <graham@mapdiva.com> wrote:

Turns out you’re right - the images were NOT square - they vary. It just so happened that the first image in my selection was square, and that’s what I observed in the debugger. Since it was in line with my expectations, it seemed to make sense. But actually later the images are rendered INTO a square, with the rectangle scaled to fit.

Anyway, NOT forcing them to be square, but instead doing the same “fit” calculation to arrive at a dragging frame solves the problem.

So thanks for getting me to examine my assumptions here - it was on the right track.
I'm glad I could help. It's just one of those things I've run into myself a million times - I _think_ I've checked all my assumptions when I'm debugging something, and end up off in the weeds (for hours or more, sometimes) because one of my basic assumptions was wrong. Fortunately, you posted that screen recording showing the behavior so I could pause it and see what the exact scaling was. Nothing like having plenty of data to look at - that makes it easy to help solve the problem.

Good luck with your app!

- Jon


Re: NSDraggingSession distorts the images I give it

Graham Cox
 

Hi Jon,

Turns out you’re right - the images were NOT square - they vary. It just so happened that the first image in my selection was square, and that’s what I observed in the debugger. Since it was in line with my expectations, it seemed to make sense. But actually later the images are rendered INTO a square, with the rectangle scaled to fit.

Anyway, NOT forcing them to be square, but instead doing the same “fit” calculation to arrive at a dragging frame solves the problem.

So thanks for getting me to examine my assumptions here - it was on the right track.

—Graham

On 6 Nov 2019, at 6:47 pm, Jon Gotow <gotow@stclairsoft.com> wrote:

I’m just relating what I’m observing in the video. Each icon is getting stretched vertically not by a uniform factor, but so that the drawn elements exactly fit the given bounds. Honestly, it looks like NSImage is ignoring the pdf media box and setting its size based on the drawn content.

Humor me here for a minute: What happens if one of the icons is a square? It’s a simple test, anyway.
Sent from my iPhone
On Nov 5, 2019, at 11:27 PM, Graham Cox <graham@mapdiva.com> wrote:

Hi Jon,

The images are square - the rect returned by -imageRectForItemAtIndex is used to render them in the view as well as supplying the frame to the NSDraggingItem. That’s why it seems odd to me that the drag changes it.

The original image is actually a PDF Representation with a size of 93, 93. The image frame for drawing (and dragging) is 76, 76. This size depends on the ‘icon size’ the user chooses for that interface - small, medium or large. 76 is the medium size. While the images themselves may not always look square, whatever is rendered has a media box that is square, and the icon is rendered centred in that square, scaled to the longer side. What that means is that no matter what overall shape the image is, the icon that results is square - it just contains some extra transparent background if needed.

In any case, the same rect is always used for rendering the image in the view and for the dragging frame. So even if it wasn’t square, they should agree.

—Graham



On 6 Nov 2019, at 4:13 pm, Jon Gotow <gotow@stclairsoft.com> wrote:

Judging from the video, your images are not square. It looks like they're only as large as they need to be to contain the drawn item, and are getting stretched to fit your square NSDraggingItem icon.

Any chance you changed the image rendering code inside of [dv imageRectForItemAtIndex:dragItemIndex] as well?

- Jon


On Nov 5, 2019, at 9:42 PM, Graham Cox <graham@mapdiva.com> wrote:

I’m modernising some old code that does drag and drop the old, simple and perfectly functional (but deprecated) way.

The new way seems twice as complicated to me, but hey-ho.

Anyway, I’m creating NSDraggingItems for each item to be dragged, and I’m setting the image and frame to sane values. When I start to drag the items however, the images are slightly resized - they expand widthways a small amount, but vertically a somewhat larger amount, making each item appear to stretch vertically. It looks like crap.

The images are actually square - and I set the image size to match the frame size, which has the same width and height.





Re: NSDraggingSession distorts the images I give it

Jon Gotow
 

I’m just relating what I’m observing in the video. Each icon is getting stretched vertically not by a uniform factor, but so that the drawn elements exactly fit the given bounds. Honestly, it looks like NSImage is ignoring the pdf media box and setting its size based on the drawn content.

Humor me here for a minute: What happens if one of the icons is a square? It’s a simple test, anyway.
Sent from my iPhone

On Nov 5, 2019, at 11:27 PM, Graham Cox <graham@mapdiva.com> wrote:

Hi Jon,

The images are square - the rect returned by -imageRectForItemAtIndex is used to render them in the view as well as supplying the frame to the NSDraggingItem. That’s why it seems odd to me that the drag changes it.

The original image is actually a PDF Representation with a size of 93, 93. The image frame for drawing (and dragging) is 76, 76. This size depends on the ‘icon size’ the user chooses for that interface - small, medium or large. 76 is the medium size. While the images themselves may not always look square, whatever is rendered has a media box that is square, and the icon is rendered centred in that square, scaled to the longer side. What that means is that no matter what overall shape the image is, the icon that results is square - it just contains some extra transparent background if needed.

In any case, the same rect is always used for rendering the image in the view and for the dragging frame. So even if it wasn’t square, they should agree.

—Graham



On 6 Nov 2019, at 4:13 pm, Jon Gotow <gotow@stclairsoft.com> wrote:

Judging from the video, your images are not square. It looks like they're only as large as they need to be to contain the drawn item, and are getting stretched to fit your square NSDraggingItem icon.

Any chance you changed the image rendering code inside of [dv imageRectForItemAtIndex:dragItemIndex] as well?

- Jon


On Nov 5, 2019, at 9:42 PM, Graham Cox <graham@mapdiva.com> wrote:

I’m modernising some old code that does drag and drop the old, simple and perfectly functional (but deprecated) way.

The new way seems twice as complicated to me, but hey-ho.

Anyway, I’m creating NSDraggingItems for each item to be dragged, and I’m setting the image and frame to sane values. When I start to drag the items however, the images are slightly resized - they expand widthways a small amount, but vertically a somewhat larger amount, making each item appear to stretch vertically. It looks like crap.

The images are actually square - and I set the image size to match the frame size, which has the same width and height.



Re: NSDraggingSession distorts the images I give it

Graham Cox
 

Hi Jon,

The images are square - the rect returned by -imageRectForItemAtIndex is used to render them in the view as well as supplying the frame to the NSDraggingItem. That’s why it seems odd to me that the drag changes it.

The original image is actually a PDF Representation with a size of 93, 93. The image frame for drawing (and dragging) is 76, 76. This size depends on the ‘icon size’ the user chooses for that interface - small, medium or large. 76 is the medium size. While the images themselves may not always look square, whatever is rendered has a media box that is square, and the icon is rendered centred in that square, scaled to the longer side. What that means is that no matter what overall shape the image is, the icon that results is square - it just contains some extra transparent background if needed.

In any case, the same rect is always used for rendering the image in the view and for the dragging frame. So even if it wasn’t square, they should agree.

—Graham

On 6 Nov 2019, at 4:13 pm, Jon Gotow <gotow@stclairsoft.com> wrote:

Judging from the video, your images are not square. It looks like they're only as large as they need to be to contain the drawn item, and are getting stretched to fit your square NSDraggingItem icon.

Any chance you changed the image rendering code inside of [dv imageRectForItemAtIndex:dragItemIndex] as well?

- Jon


On Nov 5, 2019, at 9:42 PM, Graham Cox <graham@mapdiva.com> wrote:

I’m modernising some old code that does drag and drop the old, simple and perfectly functional (but deprecated) way.

The new way seems twice as complicated to me, but hey-ho.

Anyway, I’m creating NSDraggingItems for each item to be dragged, and I’m setting the image and frame to sane values. When I start to drag the items however, the images are slightly resized - they expand widthways a small amount, but vertically a somewhat larger amount, making each item appear to stretch vertically. It looks like crap.

The images are actually square - and I set the image size to match the frame size, which has the same width and height.


Re: NSDraggingSession distorts the images I give it

Jon Gotow
 

Oh, my bad. I mean the drawing code within libItem.previewImage.

- Jon

On Nov 5, 2019, at 10:13 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Judging from the video, your images are not square. It looks like they're only as large as they need to be to contain the drawn item, and are getting stretched to fit your square NSDraggingItem icon.

Any chance you changed the image rendering code inside of [dv imageRectForItemAtIndex:dragItemIndex] as well?

- Jon


On Nov 5, 2019, at 9:42 PM, Graham Cox <graham@mapdiva.com> wrote:

I’m modernising some old code that does drag and drop the old, simple and perfectly functional (but deprecated) way.

The new way seems twice as complicated to me, but hey-ho.

Anyway, I’m creating NSDraggingItems for each item to be dragged, and I’m setting the image and frame to sane values. When I start to drag the items however, the images are slightly resized - they expand widthways a small amount, but vertically a somewhat larger amount, making each item appear to stretch vertically. It looks like crap.

The images are actually square - and I set the image size to match the frame size, which has the same width and height.

for( DKOLibraryItem* libItem in itemsToDrag )
{
NSDraggingItem* dragItem = [[NSDraggingItem alloc] initWithPasteboardWriter:libItem];
NSRect libItemRect = [dv imageRectForItemAtIndex:dragItemIndex]; // this rect is square, width = height

NSImage* icon = [libItem.previewImage copy];
icon.size = libItemRect.size;

[dragItem setDraggingFrame:libItemRect contents:icon];
[icon release];

//…. other stuff
}

Has anyone some clue what’s going on here?

Here’s a short video showing what I’m seeing. http://s3.amazonaws.com/Mapdiva/Video/Screen%20Recording%202019-11-06%20at%203.40.09%20pm.mov



—Graham




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.


Re: NSDraggingSession distorts the images I give it

Jon Gotow
 

Judging from the video, your images are not square. It looks like they're only as large as they need to be to contain the drawn item, and are getting stretched to fit your square NSDraggingItem icon.

Any chance you changed the image rendering code inside of [dv imageRectForItemAtIndex:dragItemIndex] as well?

- Jon

On Nov 5, 2019, at 9:42 PM, Graham Cox <graham@mapdiva.com> wrote:

I’m modernising some old code that does drag and drop the old, simple and perfectly functional (but deprecated) way.

The new way seems twice as complicated to me, but hey-ho.

Anyway, I’m creating NSDraggingItems for each item to be dragged, and I’m setting the image and frame to sane values. When I start to drag the items however, the images are slightly resized - they expand widthways a small amount, but vertically a somewhat larger amount, making each item appear to stretch vertically. It looks like crap.

The images are actually square - and I set the image size to match the frame size, which has the same width and height.

for( DKOLibraryItem* libItem in itemsToDrag )
{
NSDraggingItem* dragItem = [[NSDraggingItem alloc] initWithPasteboardWriter:libItem];
NSRect libItemRect = [dv imageRectForItemAtIndex:dragItemIndex]; // this rect is square, width = height

NSImage* icon = [libItem.previewImage copy];
icon.size = libItemRect.size;

[dragItem setDraggingFrame:libItemRect contents:icon];
[icon release];

//…. other stuff
}

Has anyone some clue what’s going on here?

Here’s a short video showing what I’m seeing. http://s3.amazonaws.com/Mapdiva/Video/Screen%20Recording%202019-11-06%20at%203.40.09%20pm.mov



—Graham




NSDraggingSession distorts the images I give it

Graham Cox
 

I’m modernising some old code that does drag and drop the old, simple and perfectly functional (but deprecated) way.

The new way seems twice as complicated to me, but hey-ho.

Anyway, I’m creating NSDraggingItems for each item to be dragged, and I’m setting the image and frame to sane values. When I start to drag the items however, the images are slightly resized - they expand widthways a small amount, but vertically a somewhat larger amount, making each item appear to stretch vertically. It looks like crap.

The images are actually square - and I set the image size to match the frame size, which has the same width and height.

for( DKOLibraryItem* libItem in itemsToDrag )
{
NSDraggingItem* dragItem = [[NSDraggingItem alloc] initWithPasteboardWriter:libItem];
NSRect libItemRect = [dv imageRectForItemAtIndex:dragItemIndex]; // this rect is square, width = height


NSImage* icon = [libItem.previewImage copy];
icon.size = libItemRect.size;


[dragItem setDraggingFrame:libItemRect contents:icon];
[icon release];

//…. other stuff
}

Has anyone some clue what’s going on here?




—Graham




Re: Mysterious build warning with .xib file

Graham Cox
 

Hmmm, oh well, I guess I’ll just live with it. Bigger fish to fry and all that.

Thanks!

—Graham



On 6 Nov 2019, at 1:05 pm, Quincey Morris <quinceymorris@...> wrote:

On Nov 5, 2019, at 16:03 , Graham Cox <graham@...> wrote:

Am I missing something? I’m building for 10.11 at the earliest, and that seems to be what is set throughout. So why the “Unsupported configuration”?

I see similar results. It looks like a bug.

If I set “Builds for” to “Deployment Target”, it shows the wrong deployment target (10.13 instead of 10.11), or if I choose a popup setting later than 10.13 there’s no error. It’s not clear whether it’s actually using 10.13, or using 10.11 and lying about it. Note that the build log shows “--minimum-deployment-target 10.11”.


Re: Mysterious build warning with .xib file

Quincey Morris
 

On Nov 5, 2019, at 16:03 , Graham Cox <graham@...> wrote:

Am I missing something? I’m building for 10.11 at the earliest, and that seems to be what is set throughout. So why the “Unsupported configuration”?

I see similar results. It looks like a bug.

If I set “Builds for” to “Deployment Target”, it shows the wrong deployment target (10.13 instead of 10.11), or if I choose a popup setting later than 10.13 there’s no error. It’s not clear whether it’s actually using 10.13, or using 10.11 and lying about it. Note that the build log shows “--minimum-deployment-target 10.11”.



Re: Mysterious build warning with .xib file

Carl Hoefs
 

That has happened to me when I've forgotten to change the OS targets for (1) all the xibs and (2) the project itself. But it sounds like you've got all that covered...

-Carl


On Nov 5, 2019, at 5:03 PM, Graham Cox <graham@...> wrote:

Can anyone explain this? I’m getting the following warning in my build:

<Screen Shot 2019-11-06 at 10.58.27 am.png>

But when I look at the file info for that .xib file:

<Screen Shot 2019-11-06 at 10.58.12 am.png>

And the deployment target in the target as a whole:

<Screen Shot 2019-11-06 at 10.58.54 am.png>

Am I missing something? I’m building for 10.11 at the earliest, and that seems to be what is set throughout. So why the “Unsupported configuration”?


—Graham




Mysterious build warning with .xib file

Graham Cox
 

Can anyone explain this? I’m getting the following warning in my build:


But when I look at the file info for that .xib file:


And the deployment target in the target as a whole:


Am I missing something? I’m building for 10.11 at the earliest, and that seems to be what is set throughout. So why the “Unsupported configuration”?


—Graham



BGTaskScheduler blocks when build with Xcode 11.2

Gerriet M. Denkmann
 

I have an iOS app (iOS 12.4+) which did work on iOS 12.4 … iOS 13.2 when build with Xcode 11.1.

Now I have upgraded to Xcode 11.2 and the app no longer works on iOS 13.2 devices.

When I do:
BGTaskScheduler.shared.cancelAllTaskRequests()
it does not return.
lldb tells me:

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x00000001919b4634 libsystem_kernel.dylib`mach_msg_trap + 8
frame #1: 0x00000001919b3aa0 libsystem_kernel.dylib`mach_msg + 72
frame #2: 0x0000000103b5b55c libdispatch.dylib`_dispatch_mach_send_and_wait_for_reply + 564
frame #3: 0x0000000103b5b924 libdispatch.dylib`dispatch_mach_send_with_result_and_wait_for_reply + 52
frame #4: 0x00000001917aa440 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 236
frame #5: 0x00000001920c7b9c Foundation`__NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 12
frame #6: 0x0000000191ea1074 Foundation`-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2608
frame #7: 0x0000000191ea045c Foundation`-[NSXPCConnection _sendSelector:withProxy:arg1:] + 124
frame #8: 0x00000001920ce890 Foundation`_NSXPCDistantObjectSimpleMessageSend1 + 36
frame #9: 0x00000001a496ca48 DuetActivityScheduler`-[_DASScheduler cancelAllTaskRequests] + 176
frame #10: 0x00000001ba2e5f1c BackgroundTasks`-[BGTaskScheduler cancelAllTaskRequests] + 152

What to do?

Gerriet.


Re: Puzzle with Hardened Runtime entitlement

Leo
 

On Mon, Nov 4, 2019 at 03:52 AM, Sak Wathanasin wrote:
That and the dozen or so pop-ups asking for permission that appear as soon as our app launches - all it does is condition the user to press "Allow".
Oh yeah. "Apple Event sandboxing" must be the dumbest idea Apple came up with in the area of "security" so far. Only causes countless hassles to both users and developers.

Leo


Re: Puzzle with Hardened Runtime entitlement

Sak Wathanasin
 



On 4 Nov 2019, at 04:19, Leo <leo.r@...> wrote:

-As far as I understand, provisional profiles are not required for Mac apps at all

Yup; in our manually-signed app, we just set it to "none" from the pop-up

-From my experience, for non-MAS apps, I recommend to deselect "Automatically manage signing" and do it manually with a script (I use an AppleScript droplet).


Completely agree - we use a python script, but whatever works for you

May I also advise to submit a bug to Apple (unless you already did of course). The time - and resources - we waste because of

I've spent days, if not weeks to get our CI build to work with notarization.

this poorly designed pseudo-security mumbo-jumbo is absolutely astonishing. That's only my view, of course.

That and the dozen or so pop-ups asking for permission that appear as soon as our app launches - all it does is condition the user to press "Allow".

Regards
Sak


Entitlement that allows app to run scripts that target any app

Steve Mills
 

I have an app that can launch apps and scripts. A script might target any app, so I can't use com.apple.security.temporary-exception.apple-events and add an app identifier for every possible app in the world. What entitlement do I need to use?

--
Steve Mills
Drummer, Mac geek


Re: Puzzle with Hardened Runtime entitlement

Leo
 

I don't have an answer to your particular situation, sadly, but man do I understand your pain!

I can only mention two things:

-As far as I understand, provisional profiles are not required for Mac apps at all
-From my experience, for non-MAS apps, I recommend to deselect "Automatically manage signing" and do it manually with a script (I use an AppleScript droplet).

May I also advise to submit a bug to Apple (unless you already did of course). The time - and resources - we waste because of this poorly designed pseudo-security mumbo-jumbo is absolutely astonishing. That's only my view, of course.


Leo


Re: Puzzle with Hardened Runtime entitlement

Quincey Morris
 

This isn’t, by any chance, one of those “ancient” apps that use an app ID whose prefix ISN’T your developer team ID? If so, that might have something to do with why it doesn’t work.

On Nov 3, 2019, at 19:25 , Graham Cox <graham@...> wrote:

If I uncheck ‘Automatically manage signing’, then it needs a provisioning profile I don’t have. I could probably create one, but it seems that Apple need me to change the bundle identifier so I can do that


Re: Puzzle with Hardened Runtime entitlement

Graham Cox
 

I checked that, and it’s turned on in the build settings.

There’s another oddity, which is probably the real cause.

In “signing and capabilities”, I have it set for Xcode to manage automatically. I can choose by company, but the menu for the Signing Certificate won’t let me choose ‘Development’ - it just refuses to select it and remains set to ’None’.


Also, when I do a build, I get this warning:


If I uncheck ‘Automatically manage signing’, then it needs a provisioning profile I don’t have. I could probably create one, but it seems that Apple need me to change the bundle identifier so I can do that! I simply don’t get the interaction between all these things - it just seems like a bunch of random hoops I have to jump through, with little rhyme nor reason. Changing the bundle identifier is going to break (AGAIN!!!) the continuity of updates of my app with my customers. I’m getting really sick of that, and so are they.

—Graham




On 4 Nov 2019, at 10:40 am, Shane Stanley <sstanley@...> wrote:

On 1 Nov 2019, at 12:25 pm, Graham Cox <graham@...> wrote:

I’m using Xcode 11.0

I had no problem in Xcode 10, but in the one project where I turned the hardened runtime on for the first time in Xcode 11, I had to make sure it was on in Build Settings as well as in the Signing & Capabilities tab.


Re: Puzzle with Hardened Runtime entitlement

Shane Stanley
 

On 1 Nov 2019, at 12:25 pm, Graham Cox <graham@mapdiva.com> wrote:

I’m using Xcode 11.0
I had no problem in Xcode 10, but in the one project where I turned the hardened runtime on for the first time in Xcode 11, I had to make sure it was on in Build Settings as well as in the Signing & Capabilities tab.


--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>

341 - 360 of 1426