Fix deprecated warnings for macOS #82
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
karelbilek
force-pushed
the
fix_warnings
branch
from
b439758
to
071c4c5
Compare
macOS has a new framework UniformTypeIdentifiers that needs to be used for this. Note that the behavior is not exactly the same - if you add "jpg", it will find a UTType that has "jpg" extension and will use that instead of creating a new type; so it will match both "jpg" and "jpeg". I think it is acceptable (and, probably, even better).
|
I like the sound of it, my only reservation based on the docs is this:
ie. adopting UTType would drop support for 11 years worth of operating systems. Of course we can stay on the deprecated API forever, but suddenly requiring everyone to be within 4 years of bleeding-edge seems a bit too harsh a jump. Hmm, although this is a little bit exaggerated because 11.0 does support older machines, even some laptops back to 2013. Within 10 years of bleeding-edge seems like an OK cutoff... let me sleep on it |
|
I am not sure how much does golang even support older macos-es.
would need to look it up
…On Mon 26. 2. 2024 at 15:16, sqweek ***@***.***> wrote:
I like the sound of it, my only reservation based on the docs
<https://developer.apple.com/documentation/uniformtypeidentifiers/uttype/3548216-typewithfilenameextension>
is this:
- macOS 10.6 release date: 28 August 2009
- macOS 11.0 release date: 12 November 2020
ie. adopting UTType would drop support for 11 years worth of operating
systems. Of course we can stay on the deprecated API forever, but suddenly
requiring everyone to be within 4 years of bleeding-edge seems a bit too
harsh a jump.
Hmm, although this is a little bit exaggerated because 11.0 does support
older machines, even some laptops back to 2013. Within 10 years of
bleeding-edge seems like an OK cutoff... let me sleep on it
—
Reply to this email directly, view it on GitHub
<#82 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZT4KTIVYMAORSULZX6WTYVSKM3AVCNFSM6AAAAABDPWNORCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGI2TAMJSGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
see this and similar
golang/go#57125
…On Mon 26. 2. 2024 at 15:24, Karel Bílek ***@***.***> wrote:
I am not sure how much does golang even support older macos-es.
would need to look it up
On Mon 26. 2. 2024 at 15:16, sqweek ***@***.***> wrote:
> I like the sound of it, my only reservation based on the docs
> <https://developer.apple.com/documentation/uniformtypeidentifiers/uttype/3548216-typewithfilenameextension>
> is this:
>
> - macOS 10.6 release date: 28 August 2009
> - macOS 11.0 release date: 12 November 2020
>
> ie. adopting UTType would drop support for 11 years worth of operating
> systems. Of course we can stay on the deprecated API forever, but suddenly
> requiring everyone to be within 4 years of bleeding-edge seems a bit too
> harsh a jump.
>
> Hmm, although this is a little bit exaggerated because 11.0 does support
> older machines, even some laptops back to 2013. Within 10 years of
> bleeding-edge seems like an OK cutoff... let me sleep on it
>
> —
> Reply to this email directly, view it on GitHub
> <#82 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAZT4KTIVYMAORSULZX6WTYVSKM3AVCNFSM6AAAAABDPWNORCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGI2TAMJSGA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
Interesting read. I'm not in a rush to mandate a 6-month old go version either. go 1.10 is only 6 years old and supported macOS 10.8 (it was the last go version with official support]). |
|
okay. in that case, let's leave the deprecated warnings and close this
ticket. it doesn't hurt anything. it's deprecated for a long time and they
don't seem in a hurry to remove it.
just add a comment to that piece of code so someone doesn't open the same
ticket again.
(not sure if the old go even builds this code but let's test that
separately:))
…On Mon 26. 2. 2024 at 16:46, sqweek ***@***.***> wrote:
Interesting read. I'm not in a rush to mandate a 6-month old go version
either.
go 1.10 is only 6 years old and supported macOS 10.8 (it was the last go
version with official support <golang/go#23011>
]).
—
Reply to this email directly, view it on GitHub
<#82 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZT4IQLJTT2YQDSIPIARTYVSU5RAVCNFSM6AAAAABDPWNORCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGQ3DCMZUGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
The PR above fixes it for me. I would recommend just to steam ahead, Apple push updates pretty hard. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
macOS has a new framework UniformTypeIdentifiers that needs to be used for this.
Note that the behavior is not exactly the same - if you add "jpg", it will find a UTType that has "jpg" extension and will use that instead of creating a new type; so it will match both "jpg" and "jpeg".
I think it is acceptable (and, probably, even better).