4 ms·

For another SwiftUI-like wrapper, see also https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui (used by Adawaita to genera

by w10-1 3y ago

For another SwiftUI-like wrapper, see also https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui (used by Adawaita to generate widgets, and mentioned in other comments). The key premise of this approach is to provide a SwiftUI-like declarative wrapper around Gnome functionality. It's unclear what it adds over swift-cross-ui. SwiftUI itself has growing pains mainly around being on the right thread for processing/updates and getting data binding right. Blog entries on swift.org or from Apple tend to be little demos that show the happy path, but when discussing new frameworks (like a Gnome wrapper) or platforms (like the recent embedded), I'd like more demonstration that the authors understand and address key issues and will sustain development. Cross-platform UI frameworks get complicated quickly and have a long tail of issues (cf Flutter, Java/Eclipse, et al) that can be blockers for clients/users. For Swift it doesn't help to have multiple concurrency models and obviously different behaviors on apple platforms and Linux (where UI is not officially tested).

azinman2 3y ago
I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends this. I’m also not sure how this is SwiftUI specific as UIKit and most other UI frameworks are the same. What are the growing pains here?
- w10-1 3y ago
  Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.
- brailsafe 3y ago
  Well, I've been fighting with an extremely simple Navigationsplitview for ages. Put a list in the sidebar, put 100 items in it, and render almost anything else in the detail on macos (one version back). Then select an item in the nav and hit the down arrow. Depending on implementation, scrolling will get clipped to the visible area, it'll hold onto multiple selections if the first has been scrolled off screen, or the main thread will get thrashed and performance will be about what the current settings menu is. I haven't found something that I don't have to accept a really mediocre experience with, but next I'm going to try rewriting it with NSTable

by w10-1 3y ago

azinman2 3y ago

I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends this. I’m also not sure how this is SwiftUI specific as UIKit and most other UI frameworks are the same. What are the growing pains here?

w10-1 3y ago
Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.
brailsafe 3y ago
Well, I've been fighting with an extremely simple Navigationsplitview for ages. Put a list in the sidebar, put 100 items in it, and render almost anything else in the detail on macos (one version back). Then select an item in the nav and hit the down arrow. Depending on implementation, scrolling will get clipped to the visible area, it'll hold onto multiple selections if the first has been scrolled off screen, or the main thread will get thrashed and performance will be about what the current settings menu is. I haven't found something that I don't have to accept a really mediocre experience with, but next I'm going to try rewriting it with NSTable