Re: OS/X Java native bug

[Alan Snyder via Cocoa-dev]

Your comments don’t make sense to me.

You either post an event to run the code on the main thread or, if you are on 
the main thread, you run the code directly.

Running the code directly is what invoking a block does.

How is that unnecessary?

Would it make more sense if the parameter were named “c” and the code said 
“c()”?



> On Mar 19, 2023, at 6:22 AM, Michael Hall  wrote:
> 
> 
> 
>> On Mar 18, 2023, at 4:46 AM, Michael Hall  wrote:
>> 
>>> On Mar 17, 2023, at 7:49 AM, Alan Snyder >> <mailto:javali...@cbfiddle.com>> wrote:
>>> 
>>> block() means invoke the block
>> 
>> 
>> Not exactly and it still seems unnecessary here.
>> 
>> It appears to convert the block to a selector and then to invoke it. 
> 
> There seems to be something I’m missing here. An app running with this 
> changed was crashing.
> So the separate block() call might be necessary for some reason.
> 

___

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: Entitlements of ScreenSaverEngine under macOS Mojave (10.14)

[Alan Snyder via Cocoa-dev]

Executable=/System/Library/CoreServices/ScreenSaverEngine.app/Contents/MacOS/ScreenSaverEngine
Identifier=com.apple.ScreenSaver.Engine
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=365 flags=0x0(none) hashes=4+5 location=embedded
Platform identifier=7
Hash type=sha256 size=32
CandidateCDHash sha256=d1c076eb022429c69eb591f76762740ffab13c44
Hash choices=sha256
CDHash=d1c076eb022429c69eb591f76762740ffab13c44
Signature size=4485
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=20
TeamIdentifier=not set
Sealed Resources version=2 rules=13 files=80
Internal requirements count=1 size=76

http://www.apple.com/DTDs/PropertyList-1.0.dtd;>


com.apple.developer.extension-host.screensaver

com.apple.security.cs.disable-library-validation





> On Sep 20, 2021, at 1:19 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> codesign -dvvv --entitlements :- 
> /System/Library/CoreServices/ScreenSaverEngine.app/Contents/MacOS/ScreenSaverEngine

___

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: Thoughts on Cocoa source code

[Alan Snyder via Cocoa-dev]

> On Oct 9, 2019, at 10:41 AM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> You don't want to use the _implementation_ details! Those can and do change 
> completely over time

There is a situation where I think it is fine to use the implementation 
details, and that is to work around a problem in an old release of macOS, which 
is never going to be changed (with the possible exception of a security patch, 
I suppose, but that is unlikely to cause any problems).

Believe it or not, some bugs are not fixed until the next release, or the one 
after that, or …


___

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: assertion failure

[Alan Snyder]

I understand that my program is doing it wrong. But is it normal to have an 
assertion failure, rather than an error return?



> On Apr 7, 2018, at 12:04 PM, Rob Petrovec <petr...@mac.com> wrote:
> 
> It’s saying that you are doing it wrong.  Utility windows cannot go full 
> screen.  You have yours set to go full screen.  It shouldn’t be.
> 
> —Rob
> 
> 
>> On Apr 7, 2018, at 10:24 AM, Alan Snyder <applemail832...@cbfiddle.com> 
>> wrote:
>> 
>> I am getting an assertion failure notice on the console when running a small 
>> test program:
>> 
>> Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
>> /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741
>> 
>> (This message is on 10.12.6, the details are different on 10.13.)
>> 
>> When run under Xcode, there is more information: utility panels cannot be 
>> fullscreen primary
>> 
>> My question—does this represent a bug in AppKit that I should report, or is 
>> it trying to help me by explaining that my program provided an unsupported 
>> set of style bits when creating a window?
>> 
>> Alan
>> 
>> ___
>> 
>> 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/petrock%40mac.com
>> 
>> This email sent to petr...@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

assertion failure

[Alan Snyder]

I am getting an assertion failure notice on the console when running a small 
test program:

Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741

(This message is on 10.12.6, the details are different on 10.13.)

When run under Xcode, there is more information: utility panels cannot be 
fullscreen primary

My question—does this represent a bug in AppKit that I should report, or is it 
trying to help me by explaining that my program provided an unsupported set of 
style bits when creating a window?

  Alan

___

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

NSDocument autosave in place – possible data loss?

[Alan Snyder]

I was thinking about the idea of automatic save in place, and it occurred to me 
there could be a problem.

Suppose the user wants to move some content from one place in a document to 
another. A typical way to do this would be to cut the content from the original 
location and paste it in the new location.

But suppose the document is autosaved between the cut and paste, and the app or 
system crashes before the next autosave.

Would the content then be lost, and would the user even know?

I know that autosave cannot prevent all data loss, but this seems potentially 
more serious than losing a bit of typing.

Does anyone try to deal with this potential problem?

Are there other scenarios of a similar nature?

  Alan

___

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

using AppleScript to print an HTML document

[Alan Snyder]

I’m trying to use AppleScript to get Safari to print an HTML document (showing 
the print dialog) and am having no luck with the direct approach.

This script times out without opening a print dialog or printing the document:

tell application "Safari"
print POSIX file "/Users/alan/a5.val/index.html" with print dialog
end tell


These scripts open the document, but do not open a print dialog and do not 
print the document. The first one times out.


tell application "Safari"

open POSIX file "/Users/alan/a5.val/index.html"
print document 1 with print dialog
end tell

tell application "Finder"
print POSIX file "/Users/alan/a5.val/index.html"
end tell

This workaround is the closest I have come, although I don’t really want to 
display the document in Safari:

tell application "Safari"
open POSIX file "/Users/alan/a5.val/index.html"
end tell

tell application "System Events"
set frontmost of process "Safari" to true
tell process "Safari"
keystroke "p" using command down
end tell
end tell

Also, there is a long delay before the print dialog is displayed.

Any suggestions?

___

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: Ignore Spelling not persistent?

[Alan Snyder]

Good point. Indeed, it is the responsibility of the app to save the list of 
ignored words, and there is an API it can use to restore the list into 
NSSpellChecker.

Apple’s own apps are inconsistent. Pages makes the ignored words persistent 
(although the words do not take effect immediately on reopening a document, 
presumably a bug). TextEdit and Mail do not.

Part of the implementation of persistent ignored words is to provide a way to 
remove words from the list. Pages does this. Perhaps that is just too much work 
to support in other apps.

  Alan




> On Aug 22, 2017, at 8:43 PM, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
> 
>> On Aug 22, 2017, at 6:26 PM, Alan Snyder <applemail832...@cbfiddle.com 
>> <mailto:applemail832...@cbfiddle.com>> wrote:
>> 
>> The documentation that I have seen for the Ignore Spelling contextual menu 
>> item says that it applies to the current document, but does not say one way 
>> or the other whether the setting is persistent. As far as I can tell, the 
>> setting is not persistent. That strikes me as odd. Why would one want to 
>> ignore the word only in one editing session? I imagine using this command 
>> for words that are correct in context but not correct in all contexts. Any 
>> thoughts?
> 
> I don't think the spell-checker knows how to persist data [the list of 
> ignored words] into the text being checked. In other words, it doesn't know 
> how or where you're saving that text. If you want this persistent behavior, 
> which I agree is good, you'll have to save the state of that setting, plus 
> the list of ignored words, into your document somehow. (I don't know how to 
> do this; I've never worked with the Cocoa spell-check API.)
> 
> —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

Ignore Spelling not persistent?

[Alan Snyder]

The documentation that I have seen for the Ignore Spelling contextual menu item 
says that it applies to the current document, but does not say one way or the 
other whether the setting is persistent. As far as I can tell, the setting is 
not persistent. That strikes me as odd. Why would one want to ignore the word 
only in one editing session? I imagine using this command for words that are 
correct in context but not correct in all contexts. Any thoughts?

___

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: inconsistencies in view renderings

[Alan Snyder]

If you exclude textured controls in the window content area, then my examples 
are all moot.

Can you tell me how to create a window with a bottom status bar in IB? It seems 
to depend on some sort of analysis by AppKit.





> On Oct 19, 2016, at 8:16 PM, Quincey Morris 
>  wrote:
> 
> So, clearly, there is an intention to gray out toolbars and status bars in 
> inactive window, and an intention not to gray out controls in the body of a 
> window. At a high level, doesn’t that describe the things that you’ve been 
> seeing?

___

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: inconsistencies in view renderings

[Alan Snyder]

My goal is understanding, and I'm not quite there yet.

I tried changing my program to use a textured window, and the textured buttons 
now gray out when the window is inactive.

However, the buttons are not in the toolbar or a bottom margin. At least I 
don’t think they are in a bottom margin, unless the entire window excluding the 
toolbar is a bottom margin. The buttons are within a box with a fill color.

Do you have a test of a textured button in a textured window that does not gray 
out when inactive? (I’m ignoring the fact that textured buttons are not 
supposed to be used in the content area.)

I have also noticed that if I add a template icon to the textured button, then 
the text and the icon both gray out, even in a non-textured window.

However, if I use a textured segmented control with a label and a template 
icon, the label grays out but the icon does not.

Perhaps the intent is to gray out all textured buttons in inactive windows but 
the support is buggy?

  Alan





> On Oct 18, 2016, at 8:53 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 18, 2016, at 19:43 , Alan Snyder <applemail832...@cbfiddle.com 
> <mailto:applemail832...@cbfiddle.com>> wrote:
>> 
>> Well, try this on Sierra:
>> 
>> Use the Open File… menu item of Safari to open a dialog. Then activate a 
>> different application. On my system, the Cancel button in the dialog grays 
>> out (although it still looks different than the disabled Open button). Now 
>> click the Cancel button. Even though the button is grayed out, on my system 
>> the dialog is dismissed.
> 
> Yup, that works as you say. Guess why? (You won’t like the answer.)
> 
> The buttons change appearance when they’re in a window margin at the bottom 
> of an inactive window (and, I would expect, when they’re in a toolbar at the 
> top). If they’re in the body of the window, they don’t change.
> 
> I’ve lost track of what the point is here. Apparently there is no 
> programmatic way to control to inactive appearance, and 
> “acceptsFirstResponder” only affects the inactive behavior. Is there 
> something you were trying to do that you couldn’t, or was it only about 
> explaining the apparent inconsistency?
> 

___

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: inconsistencies in view renderings

[Alan Snyder]

That sounds rather mysterious. What kind of project configuration would affect 
the display of buttons?

Well, try this on Sierra:

Use the Open File… menu item of Safari to open a dialog. Then activate a 
different application. On my system, the Cancel button in the dialog grays out 
(although it still looks different than the disabled Open button). Now click 
the Cancel button. Even though the button is grayed out, on my system the 
dialog is dismissed.

(I believe Cancel and Open are textured buttons on Sierra, as clicking them 
flashes gray, not blue.)


> On Oct 18, 2016, at 6:07 PM, Quincey Morris 
>  wrote:
> 
> If you are seeing a difference, something else is going one, such as a slight 
> configuration difference in my test project.

___

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: inconsistencies in view renderings

[Alan Snyder]

Sounds like you were not using textured rounded buttons, which are the ones 
that I wrote about.



> On Oct 18, 2016, at 1:00 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 18, 2016, at 12:17 , Alan Snyder <applemail832...@cbfiddle.com 
> <mailto:applemail832...@cbfiddle.com>> wrote:
>> 
>> The implication is that AppKit is probing the application at unspecified 
>> times with a fake event?
> 
> Well, I had to try it in a test project. I don’t see *any* difference in 
> appearance in the buttons, with acceptsFirstResponder YES or NO, regardless 
> of window state, regardless of IB canvas or running application, *except* 
> that colored highlights (the blue indicating a default button, or the blue 
> menu indicator on a popup button) change to gray in an inactive window.
> 
> This is with macOS Sierra. It’s possible that earlier iterations of the OS X 
> UI did have an inactive appearance for buttons, and my feeble recollection is 
> that this was so for a while in the 10.6-10.8 era, at least.
> 
> Perhaps what I did at the time was disable the button when the window went 
> inactive.
> 
>> Nothing in the documentation of acceptsFirstMouse suggests such a thing.
> 
> Well, the event parameter is allowed to be nil (and AppKit headers have been 
> audited for nullability, so it’s not likely to be an oversight).
> 

___

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: inconsistencies in view renderings

[Alan Snyder]

I was afraid you would say that…

The implication is that AppKit is probing the application at unspecified times 
with a fake event? Nothing in the documentation of acceptsFirstMouse suggests 
such a thing.

I have not found any other API so far.

  Alan



> On Oct 18, 2016, at 9:51 AM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 18, 2016, at 08:00 , Alan Snyder <applemail832...@cbfiddle.com> wrote:
>> 
>> Is the choice to gray or not to gray when inactive under programmer control?
> 
> IIRC you can control this by the the value of “acceptsFirstMouse”. The NSView 
> default is NO, but NSButton overrides it to return YES. To change it back 
> again, you need to subclass NSButton and override the method. (But it’s a 
> while since I’ve had to deal with this, and there may be other API for 
> directly controlling the appearance.)
> 
> 


___

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: inconsistencies in view renderings

[Alan Snyder]

Is the choice to gray or not to gray when inactive under programmer control?


> On Oct 18, 2016, at 12:08 AM, Quincey Morris 
>  wrote:
> 
> Keep in mind that buttons have *two* kinds of graying these days. One 
> indicates that the button is disabled. The other indicates that the button is 
> in an inactive window and does not accept mouse clicks until the window has 
> first been made active (thus preventing an inadvertent click on a non-front 
> window’s controls).
> 
> Typically, buttons in inactive windows *do* accept mouse clicks, and retain 
> their ungrayed appearance, which is why the appearance doesn’t change when 
> one of your windows is inactive.

___

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

inconsistencies in view renderings

[Alan Snyder]

I am not an expert on Interface Builder, so I hope to learn something about how 
IB simulates the display of views or how IB defined views are constructed at 
run time.

I have a UI that includes textured rounded buttons with text labels. In IB, 
when the IB window is inactive, the buttons display in a grayed out fashion. In 
the actual application, when the application window is inactive, the button 
displays do not change.

What might be causing this difference in rendering?

  Alan


___

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: NSImage from bitmap - then delete bitmap

[Alan Snyder]

Or better yet, have the termination request come from a thread other than the 
main thread.

> On Jul 22, 2016, at 9:38 AM, Alan Snyder <applemail832...@cbfiddle.com> wrote:
> 
> 
>> On Jul 22, 2016, at 7:45 AM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>> 
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it does this after performOnMainThread has been called by a
>> worker thread, but before the main thread has processed it, then the main
>> thread will block waiting for the worker thread to exit, but the worker
>> thread has already blocked when it called performOnMainThread.
>> 
>> Very rare, but it can happen.
> 
> This sounds like a bug to me.
> 
> Would this work: The worker thread could set a flag before it calls 
> performOnMainThread and your thread termination code could do something 
> different when this flag is set.
> 


___

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: NSImage from bitmap - then delete bitmap

[Alan Snyder]

> On Jul 22, 2016, at 7:45 AM, Trygve Inda  wrote:
> 
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block waiting for the worker thread to exit, but the worker
> thread has already blocked when it called performOnMainThread.
> 
> Very rare, but it can happen.

This sounds like a bug to me.

Would this work: The worker thread could set a flag before it calls 
performOnMainThread and your thread termination code could do something 
different when this flag is set.

___

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

debugging a deadlock involving NSViewHierarchyLock

[Alan Snyder]

I have an application that occasionally deadlocks with the main thread calling 
-[NSViewHierarchyLock _lockForWriting:handler:] and no other thread stack 
showing any operation in progress that might need to own this lock. I saved a 
core dump. Is there any way I can poke around in the core dump using lldb to 
find out which thread owns the lock?


___

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: Imported UTI taking precedence over Exported UTI

[Alan Snyder]

Have you tried lsregister -dump?


> On Jul 1, 2016, at 9:18 AM, Matthew LeRoy  wrote:
> 
> Hi,
> 
> I’m having an issue where it appears that an Imported UTI for a certain file 
> extension declared by one application is taking precedence over an Exported 
> UTI for the same file extension declared by a second application. Everything 
> I’ve read in the docs and elsewhere states that Exported UTIs take precedence 
> over Imported UTIs, so I’m not sure what’s going on.
> 
> I’ve run `mdls [filename]` on an example file, and the kMDItemContentType and 
> associated attributes that come back match those declared by the Imported 
> UTI, not the Exported UTI. This causes problems because the two applications 
> declare different UTI strings (kMDItemContentType) for the same file 
> extension. Thus, when the application with the Exported UTI displays its Open 
> File dialog, the files of the type in question are grayed out/unselectable 
> because the dialog has been told (via [NSDocumentController 
> runModalOpenPanel:forTypes:]) to choose files with the UTI string declared by 
> the Exporting application, but Launch Services is assigning the other UTI 
> string (from the Importing application) to those files.
> 
> Can anyone shed some light on what might be happening, or steps to 
> troubleshoot/rectify the issue?
> 
> Thanks!
> Matt


___

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: LSSharedFIleList API deprecated

[Alan Snyder]

> On Dec 9, 2015, at 5:04 PM, Dragan Milić  wrote:
> 
> Yeah, but I need to manage system-wide items, like favorites (found in 
> Finder’s sidebar), recent document (on system level, not my application 
> level), recent servers, etc. Finder still does that so I don’t really get the 
> response that “shared file lists are no longer supported.” The existing API 
> still works though, but being deprecated clearly shows in which direction 
> things are moving. Is that yet another feature developers are stripped of so 
> they couldn’t produce applications which mimic some of Apple’s applications 
> features?

Or maybe a new API is still under development, and Apple is giving us an early 
heads up. Would be nice if they said so…

___

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

mysterious behavior of system font metrics

[Alan Snyder]

I am using some code (Java) that assumes it is OK to create a size 1 font and 
then scale-transform it to render other font sizes.

I would not expect this to work with Yosemite system fonts, but most of the 
time it works better than expected. But sometimes it does not.

(The expected problem is that the glyph spacing is too large. That result is 
expected because the advance widths of a 12 point system font are smaller than 
12 times the advance widths of a 1 point system font.)

The mysterious behavior that I observe is that the result of [NSFont 
systemFontOfSize:1] can change over time. For example:

2015-10-28 10:22:15.033 java[19620:15284886] 
".HelveticaNeueDeskInterface-Regular 1.00 pt. P [] (0x7f8232e2a460) 
fobj=0x7f8232e2a2e0, spc=0.36"
2015-10-28 10:22:15.193 java[19620:15284886] 
".HelveticaNeueDeskInterface-Regular 1.00 pt. P [] (0x7f8232e2a460) 
fobj=0x7f823504b5b0, spc=0.36"
2015-10-28 10:22:15.257 java[19620:15284886] 
".HelveticaNeueDeskInterface-Regular 1.00 pt. P [] (0x7f8232e2a460) 
fobj=0x7f8232d157a0, spc=0.28"

Note that the space width changes from 0.36 (the normal value) to 0.28 (a value 
that works much better when scaled to 12 points).

Whether this change happens or not seems to depend upon the order in which 
things are done in the program, but I have not been able to pin down the exact 
difference.

I’ll take a wild guess — is there code in Cocoa that tries to identify apps 
that scale system fonts and alters the 1 point font to make scaling work better?

If so, is there a reliable way to make this happen? The problem I am having is 
that sometimes this does not happen.

(In case it is not obvious, I am not in a position to change how Java uses 
Cocoa fonts.)

  Alan

___

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: mysterious behavior of system font metrics

[Alan Snyder]

The log is showing the NSFont description: NSLog(@"%@", [NSFont 
systemFontOfSize:1]);

No drawing was performed until after these log messages were written. There was 
no graphics context.

In fact, no text was drawn using Core Text at all. Java does not use Core Text 
to draw text, but it does use the native font metrics, so yes, the differences 
are visible.

The results are not random. Either the space width stays at 0.36 or it changes 
to 0.28 and stays there. The only thing I cannot predict is whether it will 
change.

  Alan



> On Oct 28, 2015, at 2:13 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 28, 2015, at 12:17 , Alan Snyder <applemail832...@cbfiddle.com 
> <mailto:applemail832...@cbfiddle.com>> wrote:
>> 
>> The mysterious behavior that I observe is that the result of [NSFont 
>> systemFontOfSize:1] can change over time. For example:
>> 
>> 2015-10-28 10:22:15.033 java[19620:15284886] 
>> ".HelveticaNeueDeskInterface-Regular 1.00 pt. P [] (0x7f8232e2a460) 
>> fobj=0x7f8232e2a2e0, spc=0.36"
>> 2015-10-28 10:22:15.193 java[19620:15284886] 
>> ".HelveticaNeueDeskInterface-Regular 1.00 pt. P [] (0x7f8232e2a460) 
>> fobj=0x7f823504b5b0, spc=0.36"
>> 2015-10-28 10:22:15.257 java[19620:15284886] 
>> ".HelveticaNeueDeskInterface-Regular 1.00 pt. P [] (0x7f8232e2a460) 
>> fobj=0x7f8232d157a0, spc=0.28"
>> 
>> Note that the space width changes from 0.36 (the normal value) to 0.28 (a 
>> value that works much better when scaled to 12 points).
> 
> I dunno either, but it’s interesting that the NSFont object is (apparently) 
> the same each time, and there is (apparently) a secondary object that’s 
> different each time. (I may be off-base, though, since you don’t say how 
> these log messages are generated.)
> 
> My guess is that the secondary object is something that’s cached for a 
> particular spacing value, and that a new spacing value is calculated each 
> time you actually draw text (and, if different, causes a new secondary object 
> to be created). IIRC, the Helvetica Neue system font drawing is tweaked to 
> try to match metrics of Lucida Grande *per string drawn* (as is San Francisco 
> relative to past system fonts), so it’s not outside the bounds of possibility 
> that different spacing is used for each drawing call.
> 
> So were you actually drawing different text between the above log messages, 
> and were you actually seeing different spacing if you drew the same text 
> string repeatedly?
> 
> The other possibility that occurs to me is that NSFont objects may have 
> *multiple* secondary fobj objects, and that the log message is only reporting 
> a random one of them.
> 

___

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: mysterious behavior of system font metrics

[Alan Snyder]

Thanks for the pointer. I will post there.

  Alan



> On Oct 28, 2015, at 1:48 PM, Jens Alfke  wrote:
> 
> I believe there’s a mailing list on lists.apple.com  
> for CoreText; that might be a good place to ask.
> 

___

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