1.4.4test2 Coordinates

[dVIAN13]

@glouel The new location(coordinates) have leftover values(Eiffel tower?) I suggest possibly leaving them blank when moving to production build.. it's confusing as per my screenshot because of the times of sun rise/set. ;)

[glouel]

Haha nice catch ! Indeed that's the Eiffel Tower coordinates, those were my test coordinates, forgot to remove them as I rushed that build to fix the translation crash :) I'll leave these blank with a placeholder in next build !

[MystycTrolls]

Maybe add a find my coordinates and I got this: I just spamed it and it gave me a time it had NO numbers in it?

[MystycTrolls]

And I got this to with the brightness Screen Recording 2018-10-24 at 4.43.55 PM.zip

[glouel]

@dVIAN13 I put up 1.4.4 beta 1, I removed the default values for latitude longitudes (they will remain if you installed test2 though, just empty the fields) and added a number formatter that should keep inputs correct.

https://github.com/JohnCoates/Aerial/releases/download/v1.4.4beta1/Aerial.saver.zip

[dVIAN13]

@glouel sorry to re-open this..

I wanted to get your opinion.. Apparently(if you didn't notice), when you enter your own lat/long, say from opening the 'Maps' app, the sun rise/set is different than what apple is reporting for night-shift.. any thoughts on helping make them the same values, or another option would be to not display the night shift option if it's not available or disabled..?

Secondly, if the Mac supports/has enabled Night-Shift, does the OS store the coordinates used to calculate the system value for sun rise/set? if so, can the SS pre-populate those values in the text boxes when checked?

I guess I don't personally see the need to have both nightshift option and manual lat/long, unless your accounting for users wanting to set their time based on an alternate location..

Lastly, I also noticed the text boxes auto-round when you leave them. is that intended?

[glouel]

No worries !

• I think they use a slightly different calculation, not a coordinates issues, that may differ a bit. I use this to calculate https://github.com/ceek/solar

Here, I get about a +/- 7 min difference with night shift indeed, using the "official" calculation mode. There are several ways to calculate (I was pondering adding them), but Apple is a bit between official and "civil" calculation (closer to official).

See this : https://www.timeanddate.com/astronomy/different-types-twilight.html

To give you an idea, civil is -/+40 compared to "official" here. My guess is Apple is using official + 1° or something like that. I'm not sure if "copying" their stuff is a good idea, although I understand the discrepancy can be troubling. Maybe I can explain it better with the multiple calculation modes (and maybe add a mode that gets close to night shift would solve the thing, as an option with civil and regular, etc).

• In theory you can get coordinates through location services. This has a few issues though, the first one being I didn't manage to get it to work in my early testing 😅 But even then, one issue is you may get a prompt which can be an issue as I need to be able to rely on Aerial starting with no UI when the screensaver launches itself. I can't prompt there, and there can be reasons why you may need to get reprompted (maybe you disabled location services or something and I need to ask permission again). That's why I went with night shift, it's much easier, there's no permissions and it fixes itself if you travel. It's probably possible to implement something robust for the other mode with CoreLocation but that's probably more work than I wish to undertake right now as the permission thing is not easy to fix I think, especially since it's a fallback solution for older macs.

• Arg, that one is my fault 🙈 It's the thing that make sure you don't put letters in that does that, I'll fix it in next version ;)

[dVIAN13]

Thanks for your input and clarification, it is much appreciated! I am in agreement with your thoughts.

[glouel]

@dVIAN13 so according to these guys : https://www.timeanddate.com

The "official" mode that the library I used give are the "correct" times (modulo a few seconds). The library uses 90.83 degrees to calculate that value (per https://www.timeanddate.com/astronomy/different-types-twilight.html). If I use 90°, I get pretty much exactly the values from night shift, so it looks like Apple rounded that value :)

What I did for beta 2 is put a new menu right of the lat/long to pick the calculation mode with these values:

• Strict (0°)
• Official (0.83°)
• Civil (6°)
• Nautical (12°)
• Astronomical (18°)

Strict is the Apple like one, I'll keep Official as default, and add a help bubble describing the values.

[glouel]

beta 2 :

https://github.com/JohnCoates/Aerial/releases/download/v1.4.4beta2/Aerial.saver.zip

[dVIAN13]

Thanks @glouel. you're work and continued pursuit to improve this app is GREATLY appreciated.

[SeanMSmith]

I love the ability to choose among Civil, Nautical, and Astronomical twilight (in addition to Strict and Official, which are so close to the Night Shift values as to make no practical difference unless you can see the horizon).

I agree with dVIAN13 that it would be useful to pre-populate the latitude and longitude fields with the values from the user's current location (either as used to calculate the user's time zone e.g. in the Time & Date Preference Pane, or from Maps or some other method).

[glouel]

Yep it's about 7 mins diff here between official and strict, but strict is about even to night shift, that's why I put it there.

Personally I prefer Civil so far but I think it's gonna be season dependent !

You can look here https://github.com/JohnCoates/Aerial/issues/580#issuecomment-433134834 about the difficulty to get user coordinates, in theory it's easy but bit of a mess with permissions. Maybe some day I'll get to it.

It's fairly easy to input them from maps as a user (well, it's a bit of a mess, you need to right click your location, send to mail, then extract coordinates from the link that's in mail 😱). It's much easier from other sources, or maybe some geocoding (input your location, get coordinates). I may look at that one as an easy cope-out ;)

Getting user location programmatically afaik requires permission which is messy (but very good from a user stand point, just messy for our very specific usage).

[SeanMSmith]

Ah, privacy, of course! Should have thought of that. :)

Perhaps (for the future) a button in Aerial's Time pane to "Get current coordinates", so that any permissions dialog will appear only when the user has manually requested the current coordinates.

[MystycTrolls]

@glouel So does it give you the correct coordinates? Or do you have to get them from maps?

[glouel]

@glouel So does it give you the correct coordinates? Or do you have to get them from maps?

I don't get your question. This is a manual option for now yes, where you have to enter your coordinates yourself. It's a fallback mode for those who don't have nightshift.

Perhaps (for the future) a button in Aerial's Time pane to "Get current coordinates", so that any permissions dialog will appear only when the user has manually requested the current coordinates.

Yep that's what I'm looking at. CoreLocation on MacOS is a bit weird though, we'll see where I get with this. Ideally a button to get once and only once, and a checkbox for "try to check" that would try to get location when the screensaver starts for those that move around with their macs.

[glouel]

@SeanMSmith & @dVIAN13

After looking for pretty much everything, and finding a way to make it work on Mojave only, it's just that using location services on MacOS requires that the app/plugin is signed. This isn't documented as far as I know and kept me looking everywhere (and finding that "workaround" on Mojave which I don't use). So in beta 4 I've added a small button next to lat/long :

It will autofill for you based on your coordinates after asking for permission (probably once per build as far as I see). Can you let me know if that works for you? This should work on anything macOS > 10.6

If that works well, I might move that option up above night shift in the dialog, as I think it's better for most people to be able to calculate using your favorite method.

beta 4 : https://github.com/JohnCoates/Aerial/releases/download/v1.4.4beta4/Aerial.saver.zip

[SeanMSmith]

I'm still on High Sierra (I have a Fusion drive that will be converted to APFS upon upgrading to Mojave, and out of an abundance of caution, I'm waiting until at least 10.14.1), so I won't be able to test that.

[glouel]

@SeanMSmith I probably wasn't clear, but with a signed build this should work on anything > 10.6. I don't use the Mojave only workaround, but the builds absolutely need to be signed for it to work (beta 4 is signed so should be ok for you, works on my MBA on 10.13.6 here).

[dVIAN13]

@glouel thanks again for this addition. This should put this issue to rest for now, as I feel this is a good compromise, without adding too much overhead/user interaction. :)

[MystycTrolls]

Yep works fine nice addition

[MystycTrolls]

If that works well, I might move that option up above night shift in the dialog, as I think it's better for most people to be able to calculate using your favorite method.

I like it better to

[SeanMSmith]

Getting my current coordinates works well in High Sierra (and the coordinates are very close to those shown in Apple Maps - they diverge at the fourth decimal place, which is close enough). Three corrections:

1. Change "Today's" to "Today’s" (i.e. use a proper apostrophe)
2. Don't capitalize "sunrise" and "sunset"
3. More importantly, when the user has chosen to calculate from Civil, Nautical, or Astronomical, then change "Today’s sunrise" to "Today’s dawn" and change "Today’s sunset" to "Today’s dusk".

The help text should probably also be changed to make clear that Civil, Nautical, and Astronomical are ways of calculating the time of dawn and of dusk, not of sunrise and sunset. Perhaps something like the following:

There are two ways to calculate the sunset and sunrise time:

• Strict (0°): Calculate when the center of the Sun crosses the horizon

• Official (0.83°) : Calculate when the Sun completely crosses the horizon

Or instead of sunrise and sunset, you can pick from three options for the time of dawn and dusk:

• Civil (6°) : Calculate when the natural sunlight stops/starts requiring artificial light compensation

• Nautical (12°) : Calculate when stars stop/start being seen

• Astronomical (18°) : Calculate the point when the sun no longer interferes with astronomical observations

(Note also that I have suggested swapping "start/stop" for "stop/start" in the help text above to correspond with dawn/dusk, adding "center of" to the definition of Strict, and correcting the spelling of "interfere".)

[glouel]

Will fix tomorrow thanks!

[glouel]

Getting my current coordinates works well in High Sierra (and the coordinates are very close to those shown in Apple Maps - they diverge at the fourth decimal place, which is close enough).

Good ! Core Location gets pretty close usually, it's really good (considering the lack of GPS on Macs)

1. Change "Today's" to "Today’s" (i.e. use a proper apostrophe)

Is that the default apostrophe on QWERTY keyboard ?

2. Don't capitalize "sunrise" and "sunset"
3. More importantly, when the user has chosen to calculate from Civil, Nautical, or Astronomical, then change "Today’s sunrise" to "Today’s dawn" and change "Today’s sunset" to "Today’s dusk".

Ok.

The help text should probably also be changed to make clear that Civil, Nautical, and Astronomical are ways of calculating the time of dawn and of dusk, not of sunrise and sunset. Perhaps something like the following:

There are two ways to calculate the sunset and sunrise time:

• Strict (0°): Calculate when the center of the Sun crosses the horizon
• Official (0.83°) : Calculate when the Sun completely crosses the horizon

Or instead of sunrise and sunset, you can pick from three options for the time of dawn and dusk:

• Civil (6°) : Calculate when the natural sunlight stops/starts requiring artificial light compensation
• Nautical (12°) : Calculate when stars stop/start being seen
• Astronomical (18°) : Calculate the point when the sun no longer interferes with astronomical observations

(Note also that I have suggested swapping "start/stop" for "stop/start" in the help text above to correspond with dawn/dusk, adding "center of" to the definition of Strict, and correcting the spelling of "interfere".)

Added as is, thanks ! I also moved up coordinate mode on top of the panel as the preferred method.

[glouel]

(sorry for the spam, using this for the new screenshots)

[SeanMSmith]

1. Change "Today's" to "Today’s" (i.e. use a proper apostrophe)

Is that the default apostrophe on QWERTY keyboard ?

The default apostrophe on a QWERTY keyboard is “ ' ”, what is sometimes called a “typewriter apostrophe.”

See https://en.wikipedia.org/wiki/Apostrophe#Typographic_form and the following two sections, in particular https://en.wikipedia.org/wiki/Apostrophe#Entering_apostrophes.

On a Mac, pressing Option-Shift-] is the easiest way to type a proper “typographic apostrophe” (if your word processor doesn’t automatically convert typewriter to typographic apostrophes, as many now do).

Macs have had this ability to easily produce proper typographic apostrophes since 1984, and the fact that even today, 34 years later, Windows users must type Alt+0146 on the number pad to enter one (if their word processor or text editor doesn’t have a function to produce one) just boggles my mind. (And this is why I cringe when I see typewriter apostrophes in Mac software!) :-)

[glouel]

1. Change "Today's" to "Today’s" (i.e. use a proper apostrophe)

Is that the default apostrophe on QWERTY keyboard ?

The default apostrophe on a QWERTY keyboard is “ ' ”, what is sometimes called a “typewriter apostrophe.”

See https://en.wikipedia.org/wiki/Apostrophe#Typographic_form and the following two sections, in particular https://en.wikipedia.org/wiki/Apostrophe#Entering_apostrophes.

Ha, didn't know about the history of it, the ink saving thing, kinda crazy come to think of it that it never changed !

In programming ' is also very much used which probably explains why it never went to be the default apostrophe.

On a Mac, pressing Option-Shift-] is the easiest way to type a proper “typographic apostrophe” (if your word processor doesn’t automatically convert typewriter to typographic apostrophes, as many now do).

Yep, I knew Pages do that (and Word on Windows)

Macs have had this ability to easily produce proper typographic apostrophes since 1984, and the fact that even today, 34 years later, Windows users must type Alt+0146 on the number pad to enter one (if their word processor or text editor doesn’t have a function to produce one) just boggles my mind. (And this is why I cringe when I see typewriter apostrophes in Mac software!) :-)

Hehe, well it's fixed now ;) Interestingly it seems macOS UI (in french at least) uses the typographic apostrophes too !

[glouel]

I'm still on High Sierra

@SeanMSmith Can you please take a second and tell me if you have this bug on High Sierra too ? See here : https://github.com/JohnCoates/Aerial/issues/586

Many thanks !

And if you have another second, a quick look at this too : https://github.com/JohnCoates/Aerial/pull/603