Re: Confusion about screen resolution

[Ken Thomases via Cocoa-dev]

On Feb 22, 2020, at 9:02 AM, Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
>> 
>> No, the default on recent Macs is scaled to slightly under 2x.
>> 
> 
> It is about ~ 1.7 .
> 
> this means that every view has to be scaled by this odd factor, before 
> writing its contents into the frame buffer.
> I am curious as to why that doesn't cause any aliasing artefacts, or 
> anti-aliasing artefacts ...

For Retina displays, the backing store's size is always 2x the size in points 
that Cocoa reports.  The backing store is then scaled to the display's physical 
resolution.

Also, even if though the default point-size-to-display-physical-pixels used to 
be 2x, remember that other scaling was always supported.  The fact that the 
default has changed doesn't introduce a *new* problem.  Apple always had to 
have a solution for this.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Confusion about screen resolution

[Ken Thomases via Cocoa-dev]

On Feb 22, 2020, at 2:48 PM, Rick Aurbach via Cocoa-dev 
 wrote:
> 
> I think you are confusing pixels and points.
> 
> A pixel is an addressable light-emitting area on the screen. Your screen 
> contains 2880 X 1800 pixels.
> 
> But a typographical  point is a unit of distance. There are [72] points per 
> inch. (I.e., a typographical point is 0.0139 inches or 0.353 mm).

You are correct to emphasize the difference between points and pixels.  
However, points (as used by Apple) are *not* typographical points.  They are 
arbitrary.

>From 
>:

"When used in reference to high resolution in OS X, points in user space do not 
have any relation to measurements in the physical world."


In particular, you can set macOS to scale the display to other point sizes.  A 
point can't equal 1/72" in all of them.  And, of course, many monitors were ~96 
DPI for a long time back when pixels and points were equivalent.

-Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Detect when a process has stopped responding?

[Ken Thomases via Cocoa-dev]

On Dec 30, 2019, at 3:19 PM, James Walker via Cocoa-dev 
 wrote:
> 
> Some Apple utilities such as Activity Monitor can detect when a process has 
> stopped responding to events.  Is there any way to do that using public APIs?

You might be able to do it by sending the process in question an innocuous 
Apple Event with a timeout.  If it doesn't respond within the timeout, it's 
probably stuck.  Of course, these days, that requires user permission.  Also, 
it's a polling strategy, which isn't ideal.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTimer +timerWithTimeInterval:

[Ken Thomases via Cocoa-dev]

Does this happen only when launched from Xcode, or also when launched normally? 
 Does this happen with a different user account?  Does it happen when run on 
another Mac?

-Ken

> On Apr 29, 2020, at 4:35 PM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> There are no extensions or categories in the project. 
> I changed the -newData: method name to -arrivalOfNewData:. 
> I changed the newTimer variable name to theTimer. 
> I rebooted the machine. 
> 
> No joy.
> 
> I realize this is no longer a Cocoa problem, but what - even theoretically - 
> could cause this? 
> As shown in the debugger, the timer gets created with the wrong time interval 
> value, by a consistent factor of 20.
> 
> -Carl
> 
> 
>> On Apr 29, 2020, at 2:24 PM, Andy Lee  wrote:
>> 
>> I did the same just now in a macOS project.  Copied your code and added a 
>> newData: method.  This is with Xcode 11.2.1 on Mojave, 10.4.6.  Works fine 
>> for me.  Weird!
>> 
>> @implementation AppDelegate
>> 
>> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>>NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0  // should be 1/sec
>>target:self
>>  selector:@selector(newData:)
>>  userInfo:nil
>>   repeats:YES];
>>[[NSRunLoop mainRunLoop] addTimer:newTimer
>>  forMode:NSRunLoopCommonModes];
>> }
>> 
>> - (void)newData:(NSTimer *)timer {
>>NSLog(@"timer is %@", timer);
>> }
>> 
>> @end
>> 
>> 2020-04-29 17:20:45.331469-0400 NSTimerQuestion[21676:3985041] Metal API 
>> Validation Enabled
>> 2020-04-29 17:20:46.413190-0400 NSTimerQuestion[21676:3985041] timer is 
>> <__NSCFTimer: 0x6370eb80>
>> 2020-04-29 17:20:47.412968-0400 NSTimerQuestion[21676:3985041] timer is 
>> <__NSCFTimer: 0x6370eb80>
>> 2020-04-29 17:20:48.413525-0400 NSTimerQuestion[21676:3985041] timer is 
>> <__NSCFTimer: 0x6370eb80>
>> 2020-04-29 17:20:49.413373-0400 NSTimerQuestion[21676:3985041] timer is 
>> <__NSCFTimer: 0x6370eb80>
>> 2020-04-29 17:20:50.412610-0400 NSTimerQuestion[21676:3985041] timer is 
>> <__NSCFTimer: 0x6370eb80>
>> ...
>> 
>> --Andy
>> 
>> On Apr 29, 2020, at 5:15 PM, Alex Zavatone via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> I used your code in an iOS project and it works as expected.
>>> 
>>> 2020-04-29 16:14:02.254107-0500 Timer[83275:13268128] Wed Apr 29 16:14:02 
>>> 2020
>>> 2020-04-29 16:14:03.254048-0500 Timer[83275:13268128] Wed Apr 29 16:14:03 
>>> 2020
>>> 2020-04-29 16:14:04.253957-0500 Timer[83275:13268128] Wed Apr 29 16:14:04 
>>> 2020
>>> 2020-04-29 16:14:05.254170-0500 Timer[83275:13268128] Wed Apr 29 16:14:05 
>>> 2020
>>> 2020-04-29 16:14:06.254490-0500 Timer[83275:13268128] Wed Apr 29 16:14:06 
>>> 2020
>>> 2020-04-29 16:14:07.254570-0500 Timer[83275:13268128] Wed Apr 29 16:14:07 
>>> 2020
>>> 2020-04-29 16:14:08.254651-0500 Timer[83275:13268128] Wed Apr 29 16:14:08 
>>> 2020
>>> 2020-04-29 16:14:09.253715-0500 Timer[83275:13268128] Wed Apr 29 16:14:09 
>>> 2020
>>> 2020-04-29 16:14:10.254741-0500 Timer[83275:13268128] Wed Apr 29 16:14:10 
>>> 2020
>>> 
>>> I’ll mail you the project offlist.
>>> 
>>> 
>>> 
 On Apr 29, 2020, at 4:07 PM, Carl Hoefs via Cocoa-dev 
 mailto:cocoa-dev@lists.apple.com>> wrote:
 
 On Apr 29, 2020, at 1:53 PM, Carl Hoefs via Cocoa-dev 
 mailto:cocoa-dev@lists.apple.com>> wrote:
> 
> On Apr 29, 2020, at 1:43 PM, Steve Mills via Cocoa-dev 
> mailto:cocoa-dev@lists.apple.com> 
> >> 
> wrote:
>> 
>> On Apr 29, 2020, at 15:36:23, Carl Hoefs via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> When I issue NSTimer's +timerWithTimeInterval: method, I'm getting 
>>> unexpected timer firing times (20X faster than expected).
>>> 
>>> ∙ If I specify 1.0 for the time interval, my method gets called 20 
>>> times/sec. 
>>> ∙ If I specify 20.0 for the time interval, my method gets called 1 
>>> time/sec.
>>> ∙ If I specify 100.0 for the time interval, my method gets called 5 
>>> times/sec.
>>> ...etc.
>>> 
>>> Here is my only invocation, called once and nevermore:
>>> 
>>>   NSTimer *newTimer = [NSTimer timerWithTimeInterval:1.0  // should be 
>>> 1/sec
>>>   target:self
>>> selector:@selector(newData:)
>>> userInfo:nil
>>>  repeats:YES];
>>>   [[NSRunLoop mainRunLoop] addTimer:newTimer 
>>> forMode:NSRunLoopCommonModes];
>> 
>> Sounds like multiple timers are being installed. Set a breakpoint that 
>> logs when hit.

Re: [OT] Re: NSTimer +timerWithTimeInterval:

[Ken Thomases via Cocoa-dev]

On Apr 29, 2020, at 5:27 PM, Sandor Szatmari via Cocoa-dev 
 wrote:
> 
>> On Apr 29, 2020, at 17:12, Alex Zavatone via Cocoa-dev 
>>  wrote:
>> 
>> Not sure about this, but in Objective-C, you’re not supposed to start 
>> methods with new.
> 
> I’ve always operated under the premise that using a reserved prefix, such as 
> new, was not verboten.  Rather, if one chose the prefix new one must ensure 
> that the method followed memory management conventions, and would return an 
> object with a +1 retain count.  Am I mistaken about this?

No, you're not mistaken.  That's correct.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Confusion about System Preferences

[Ken Thomases via Cocoa-dev]

On Jul 9, 2020, at 3:41 AM, Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
> I am confused about the way system preferences are organized (or preferences 
> in general).
> 
> I read the man page of defaults(1), but it is still unclear to me what happens
> when I do, for instance,
> 
>  defaults -currentHost read com.apple.screensaver idleTime
> 
> as opposed to 
> 
>  defaults read com.apple.screensaver idleTime
> 
> I get different results in the two cases.
> Yet, the System Preferences GUI shows me only the value I get from 
> "currentHost",
> and that is also the idle time after which the screensaver on my laptop gets 
> launched by macOS,
> so it seems to be he only value I should care about.
> 
> So, what is the significance of the value of the version without 
> "currentHost" ?
> When is it important?

Basically, it's not important.  Something or someone erroneously set that 
preference in a non-host-specific domain, but nothing uses that 
non-host-specific value.  (For example, somebody may have issued the command 
"defaults write com.apple.screensaver idleTime -int 5", unwittingly leaving out 
"-currentHost".)

It would be used as a fallback if there were no host-specific setting, as part 
of the normal search path.  However, it's not normally set in a 
non-host-specific domain, at all.


In general, preferences are organized in a hierarchy of domains, from most 
specific to least specific.

1

Current User

Current Application

Current Host

2

Current User

Current Application

Any Host

3

Current User

Any Application

Current Host

4

Current User

Any Application

Any Host

5

Any User

Current Application

Current Host

6

Any User

Current Application

Any Host

7

Any User

Any Application

Current Host

8

Any User

Any Application

Any Host


In most cases, an app will set a preference in the Current User, Current 
Application, Any Host domain.  Generally, an app will search for a preference 
in the domains in the order listed, using the first one it finds.  (The APIs do 
the searching for the app.  The app simply doesn't override that standard 
behavior most of the time.)

However, in certain situations, it makes more sense for the app to set the 
preference for the Current Host, not Any Host.  For example, consider a 
network-mounted home folder that a user may use from a variety of different 
Macs.  Because different Macs may have different power constraints (battery vs. 
plugged in) or privacy concerns (public vs. private), they may want the screen 
saver to kick in after different intervals on different hosts.  So, the screen 
saver idle time is stored per-host.  That choice is entirely up to the software 
which stores the preference value, usually the Desktop & Screen Saver pane of 
System Preferences.

There's nothing preventing other code from setting the value in other domains 
(except that it requires admin privileges to set a preference for Any User).  
Whether that value gets used in actuality depends on the search path and the 
presence or absence of values set earlier in the search.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Ken Thomases via Cocoa-dev]

On Jun 9, 2020, at 8:11 AM, Gabriel Zachmann  wrote:
> 
>> In particular, you're not taking into account the current screen resolution 
>> (a.k.a. display mode).  The user can select different scaling for a Retina 
>> display in System Preferences > Displays.
> 
> Good point.
> I wasn't taking that into consideration.
> 
> So, what would be a robust way to determine whether or not a window (as 
> reported by "System Events") has a fullscreen size?
> 
> Or is there another way to determine whether or not an app is in fullscreen?
> 
>> First, you're going to have to explain exactly what you're planning to do 
>> with the results of your calculation.  Do you really want the physical 
>> screen size?  Or do you want the size of the 
> 
> I only want to have a little shell script 
> (or other little utility ) that runs inconspicuously in the background (or in 
> the top right menu bar) and launches a specific app once the user has been 
> inactive for a while,
> UNLESS there is another app running at the moment in fullscreen.
> 
> Does anyone have some code they could share?

You could do, for example:

python -c 'import AppKit ; print 
AppKit.NSScreen.screens()[0].frame().size.width'

Similarly for height.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Ken Thomases via Cocoa-dev]

On Jun 8, 2020, at 4:43 PM, Gabriel Zachmann via Cocoa-dev 
 wrote:
> 
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
> 
> Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process
> 
> (which I execute from my bash script using osascript) apparently does NOT 
> return window sizes in pixels. I guess it's the strange "Apple points" units. 
> According to my experiments, on my MacBook Pro Retina, for instance, a 
> fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
> By contrast, system_profiler reports 2880 x 1800.
> 
> So, the question is: how can I determine the screen size of a Mac from my 
> bash script in the same units like "System Events" uses? 
> Or, how can I determine the factor by which I have to convert pixels into 
> those other units?

I'm not sure what you're trying to do necessarily makes sense.  In particular, 
you're not taking into account the current screen resolution (a.k.a. display 
mode).  The user can select different scaling for a Retina display in System 
Preferences > Displays.  So, a screen with that's physically 5120x2880 pixels 
is, by default, in a mode that's 2560x1440 points and 5120x2880 pixels in the 
backing buffer.  However, it may also be in a mode that's just 1600x900 points 
with a 3200x1800-pixel backing buffer.  Or a mode that's 3200x1800 points with 
a 6400x3600-pixel backing buffer (which is ultimately scaled down to the 
5120x2880 physical pixels of the display).

So, basically what I'm saying is that there's no fixed relationship between 
points (for window sizes, etc.) and the number of physical pixels of a 
display's size, even if you know the screen is a Retina display.

First, you're going to have to explain exactly what you're planning to do with 
the results of your calculation.  Do you really want the physical screen size?  
Or do you want the size of the current display mode?

Then, you probably are going to have to use APIs to get the info you need.  
However, you don't necessarily have to build a C utility for it.  You can 
invoke the Swift interpreter to execute code from your script.  Or, you could 
use Python and the PyObjC bridge.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Points vs pixels in a bash script

[Ken Thomases via Cocoa-dev]

Except that Apple specifically says they're not.  From High Resolution 
Guidelines for OS X 
>:

> Note: The term points has its origin in the print industry, which defines 72 
> points as to equal 1 inch in physical space. When used in reference to high 
> resolution in OS X, points in user space do not have any relation to 
> measurements in the physical world.

In any case, it would be impossible for points to correspond to 1/72 of an 
inch, because a given physical screen size can correspond to a different number 
of points, depending on the display mode.

Regards,
Ken

> On Jun 8, 2020, at 6:01 PM, Jeff Younker via Cocoa-dev 
>  wrote:
> 
> Just as an aside, points are not Apple-specifc. They are a typesetting unit
> equivalent to 1/72 of an inch. It's the same unit used for font sizes.
> 
> -jeff
> 
> 
> On Mon, Jun 8, 2020 at 2:43 PM Gabriel Zachmann via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> 
>> I know this mailing list might not be the perfect fit for my question,
>> but maybe someone has an idea.
>> 
>> I have a problem converting points (I think) to pixels in a bash script.
>> I'd rather not write an extra C/Cocoa utility for that.
>> 
>> Using
>>   system_profiler SPDisplaysDataType
>> I can retrieve the size of a Mac's display in pixels.
>> 
>> However, the command
>> 
>>   tell application "System Events" to get the size of every window of
>> every process
>> 
>> (which I execute from my bash script using osascript) apparently does NOT
>> return window sizes in pixels. I guess it's the strange "Apple points"
>> units. According to my experiments, on my MacBook Pro Retina, for instance,
>> a fullscreen app (e.g., Keynote presentation) has a window size of 1680 x
>> 1050.
>> By contrast, system_profiler reports 2880 x 1800.
>> 
>> So, the question is: how can I determine the screen size of a Mac from my
>> bash script in the same units like "System Events" uses?
>> Or, how can I determine the factor by which I have to convert pixels into
>> those other units?
>> 
>> 
>> Many thanks in advance for any insights or hints.
>> 
>> Best regards, Gabriel
>> 
>> ___
>> 
>> 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/jeff%40drinktomi.com
>> 
>> This email sent to j...@drinktomi.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/ken%40codeweavers.com
> 
> This email sent to k...@codeweavers.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