Live data from Hacker News

Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

infoq.com

41–50 of 308 posts

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#41
post #16

Earlier quoted context omitted.

Apple is strengthening their services revenue. They week profit from the extra reach. Also, people will continue to but their hardware because the alternatives aren’t that great Simple example.... the MacBook trackpad

Ten years ago when I was offered a choice, I told the office manager I wanted a MacBook because of the trackpad. Apple’s trackpads are even better now. How has nobody figured out Apple’s 2010s trackpad technology?

They don't care because, for all of the faults of Apple's desktop/laptop strategy, the non-Apple strategy continues to be "copy form factor, invest nothing in user experience".

Edit: I knew this would get downvotes, but it's true in my experience. The closest exception is Microsoft themselves, and even then their hardware focus is limited and mostly intended as a demonstration for their OS customers.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#42
post #25

Earlier quoted context omitted.

How has nobody figured out Apple’s 2010s trackpad technology? I think because the focus is so much on the trackpad technology itself, which may be a misplaced focus. My fear is that the solution may involve rearchitecting the entire application-GUI stack to get it working on Linux. Why? Because Apple's trackpad is not a mouse emulator, it's a first class input device all the way up to the application. Trying to make…

Eh, I think you're overblowing it a bit. While Apple's trackpad does do some unique things (like Chinese character input[1]), most of the behavior that people are interested in emulating here can be reduced to the cursor position, click events, and (high-resolution) scroll events. The only part of this that isn't currently available on Linux, AFAIK, is the scrolling bits, and even that isn't critical. [1]: https://su…

As someone who's put a ridiculous amount of effort into mouse-specific user experience, I agree. Apple's only physical/technical advantages are resolution and accuracy (and they only have that because they have software that justifies the cost). The real advantage is they spent research and engineering hours, LOTS of them, determining how to give the best user experience for the majority of their users, including users coming from other platforms with other expectations.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#43

Whenever I've looked at examples on Swift on Linux in the past, the code always started with (hazy memory here) `use glibc` or similar, whereas the macOS version used a different library. So for example even just to produce a random number you had to use two completely different library functions imported with completely different names. All that to say: it's always felt to me like "cross-platform" for Swift means "t…

Probably UIKit versus Foundation. UIKit is iOS/Mac only and I think indirectly includes Foundation, which is where the essential non-UI APIs are.

All this really means is you don’t get the iOS UI tools for your Windows and Linux projects.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#44
post #25

Earlier quoted context omitted.

How has nobody figured out Apple’s 2010s trackpad technology? I think because the focus is so much on the trackpad technology itself, which may be a misplaced focus. My fear is that the solution may involve rearchitecting the entire application-GUI stack to get it working on Linux. Why? Because Apple's trackpad is not a mouse emulator, it's a first class input device all the way up to the application. Trying to make…

Eh, I think you're overblowing it a bit. While Apple's trackpad does do some unique things (like Chinese character input[1]), most of the behavior that people are interested in emulating here can be reduced to the cursor position, click events, and (high-resolution) scroll events. The only part of this that isn't currently available on Linux, AFAIK, is the scrolling bits, and even that isn't critical. [1]: https://su…

> AFAIK, is the scrolling bits, and even that isn't critical.

It seems that this is in fact the chief complaint of the folks who commented above you. It seems like they're saying that they choose to purchase alternative goods because of that behavior. That seems critical to me, no?

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#45

Whenever I've looked at examples on Swift on Linux in the past, the code always started with (hazy memory here) `use glibc` or similar, whereas the macOS version used a different library. So for example even just to produce a random number you had to use two completely different library functions imported with completely different names. All that to say: it's always felt to me like "cross-platform" for Swift means "t…

Random numbers, at least, are now part of the standard library.

As for the rest, it depends on what you consider "basic functionality". AppKit/UIKit is probably never going to be ported.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#46
post #40

> It is not clear at the moment if Apple has any plans to port Swift UI to Windows and/or Linux It seems pretty clear they have 0 plans on doing that. They could've open sourced it in the first place, along with Combine. Not open sourcing Combine seems like a pretty short sighted decision to me.

The important aspect of SwiftUI is tight integration with AppKit and UIKit. SwiftUI for Win32 (or whatever) would be a completely different beast.

There's nothing stoping anyone from implementing such a thing, just as someone wrote a SwiftUI for HTML. All the pieces are there, but it would be a huge amount of work unrelated to SwiftUI on Mac and iOS.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#47
post #40

> It is not clear at the moment if Apple has any plans to port Swift UI to Windows and/or Linux It seems pretty clear they have 0 plans on doing that. They could've open sourced it in the first place, along with Combine. Not open sourcing Combine seems like a pretty short sighted decision to me.

Swift wasn't originally open-source, either.

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#48
post #25

Earlier quoted context omitted.

How has nobody figured out Apple’s 2010s trackpad technology? I think because the focus is so much on the trackpad technology itself, which may be a misplaced focus. My fear is that the solution may involve rearchitecting the entire application-GUI stack to get it working on Linux. Why? Because Apple's trackpad is not a mouse emulator, it's a first class input device all the way up to the application. Trying to make…

Eh, I think you're overblowing it a bit. While Apple's trackpad does do some unique things (like Chinese character input[1]), most of the behavior that people are interested in emulating here can be reduced to the cursor position, click events, and (high-resolution) scroll events. The only part of this that isn't currently available on Linux, AFAIK, is the scrolling bits, and even that isn't critical. [1]: https://su…

It isn't just that. The scrolling in macOS is 2D (you can scroll a small rectangle inside a large one in any direction) and has position, velocity, acceleration, and a bounce effect on the boundaries of the content area. Additionally, you can pinch to zoom (in and out) and the zooming is smooth and continuous centred on the cursor location.

There are also various 3-finger swipe gestures, and force touch lets you click on things with different levels of force to do different things.

The only Linux application I've seen that uses smooth scrolling with acceleration is Firefox, and that isn't nearly as smooth as macOS scrolling (which is available in every application).

Re: Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

#50
post #28

Earlier quoted context omitted.

not OP either. but i think the problem is simple. apple said no to opengl, which any other platform out there supports. btw, they are even deprecating opengl! i have no idea what that means for the tons of games written with an opengl backend. probably not an issue for the iOS ecosystem though. so that's what is going on...

OpenGL isn't relevant here, as SDL2 has a metal backend that's used by default on MacOS. See https://hg.libsdl.org/SDL/rev/1acae5590352

[deleted]
Post reply on HN