3 ms·

Yup. On macOS you can use the iOS build of EX already today (i daily drive it, and it’s very usable). Meanwhile, I built an unreleased prototype of a possible

Yup. On macOS you can use the iOS build of EX already today (i daily drive it, and it’s very usable). Meanwhile, I built an unreleased prototype of a possible EX Desktop which uses Tauri + matrix-rust-sdk (codenamed aurora) - weirdly enough it feels almost identical to Element X iOS, which makes sense given all the heavy lifting in EX is matrix-rust-sdk. Separately to the aurora experiment, the Element Web/Desktop codebase itself is starting to move to a MVVM model to support swapping out the underlying SDK (e.g. for a WASMified matrix-rust-sdk) and avoid an Element X Mobile style rewrite. That said, making matrix-rust-sdk work on WASM is not trivial (especially if you want to avoid maintaining two different FFI layers for wasm-bindgen and uniffi). Another track is that matrix-js-sdk is also sprouting Simplified Sliding Sync support - I even demoed it in the Matrix 2.0 talk: https://youtu.be/ZiRYdqkzjDU?t=617 https://youtu.be/ZiRYdqkzjDU?t=617. And it already has Next Gen Auth and Element Call support. So there's also a chance that "Element X Web/Desktop" just ends up being an evolution of the current codebase - I guess this is the default path right now. Finally, there are other clients built on matrix-rust-sdk - e.g. GNOME Fractal is shaping up to be an excellent fully native GTK4 Rust desktop client, and given it shares the same engine as Element X, is suspiciously similar in terms of capabilities and perf (although I can't remember if they've enabled sliding sync yet). https://gitlab.gnome.org/World/fractal https://gitlab.gnome.org/World/fractal

iknowstuff 2y ago
Any plans for a mac catalyst version of element x? I recall Rust was a blocker for that a few years back, but after I fixed Rust’s mac catalyst support to enable fat builds of matrix rust sdk for it, it turned out there was another blocking library. the UIKit app has weird scaling and doesn’t have the nice macOS translucent sidebar/toolbar etc
- Arathorn 2y ago
  So I did a catalyst build of EX a while back (which is where https://github.com/rust-lang/rust/issues/106021 https://github.com/rust-lang/rust/issues/106021 came from) - but rather anticlimactically the end result looked almost identical to the normal iOS app when running under macOS; I don't remember the sidebar/toolbar looking particularly better, and that was my main reason for doing the build in the first place (to get a flexibly resizable left toolbar). The main advantage seemed to be that it would run on Intel. If things have improved I'd love to know, and then perhaps we'll have another shot at it. Are there any good comparison screenshots of the two approaches (with a toy app, i guess) anywhere?
  - iknowstuff 2y ago
    I think the benefit is more that you get access to AppKit APIs. This lets you integrate with the OS the way users expect. For example wrt scaling, Apple’s Mac Catalyst guide says: > When you first create your Mac app using Mac Catalyst, Xcode defaults to the “Scale Interface to Match iPad” setting, or iPad idiom. With this setting, the system ensures that your Mac app appears consistent with the macOS display environment without requiring significant changes to the app’s layout. However, text and graphics may appear slightly less detailed because iPadOS views and text scale down to 77% in macOS when you use the iPad idiom. For example, the system scales text that uses the iPadOS baseline font size of 17pt down to 13pt in macOS. So you gotta change that setting, and then use whatever SwiftUI components (or straight up AppKit APIs) allow for that native look :)

iknowstuff 2y ago

Any plans for a mac catalyst version of element x? I recall Rust was a blocker for that a few years back, but after I fixed Rust’s mac catalyst support to enable fat builds of matrix rust sdk for it, it turned out there was another blocking library. the UIKit app has weird scaling and doesn’t have the nice macOS translucent sidebar/toolbar etc

Arathorn 2y ago
So I did a catalyst build of EX a while back (which is where https://github.com/rust-lang/rust/issues/106021 https://github.com/rust-lang/rust/issues/106021 came from) - but rather anticlimactically the end result looked almost identical to the normal iOS app when running under macOS; I don't remember the sidebar/toolbar looking particularly better, and that was my main reason for doing the build in the first place (to get a flexibly resizable left toolbar). The main advantage seemed to be that it would run on Intel. If things have improved I'd love to know, and then perhaps we'll have another shot at it. Are there any good comparison screenshots of the two approaches (with a toy app, i guess) anywhere?
- iknowstuff 2y ago
  I think the benefit is more that you get access to AppKit APIs. This lets you integrate with the OS the way users expect. For example wrt scaling, Apple’s Mac Catalyst guide says: > When you first create your Mac app using Mac Catalyst, Xcode defaults to the “Scale Interface to Match iPad” setting, or iPad idiom. With this setting, the system ensures that your Mac app appears consistent with the macOS display environment without requiring significant changes to the app’s layout. However, text and graphics may appear slightly less detailed because iPadOS views and text scale down to 77% in macOS when you use the iPad idiom. For example, the system scales text that uses the iPadOS baseline font size of 17pt down to 13pt in macOS. So you gotta change that setting, and then use whatever SwiftUI components (or straight up AppKit APIs) allow for that native look :)