search

MerosCrypto / Meros

An instant and feeless cryptocurrency for the future, secured by the Merit Caching Consensus Mechanism.
https://meroscrypto.io
Other
83 stars 19 forks source link

GUI should probably be based off of Wry, not Webview. #303

Closed kayabaNerve closed 3 years ago

kayabaNerve commented 3 years ago

Wry is actively developed, in Rust, and has a thoroughly established team around it. Being in Rust means increased safety, yet we'll also need two sets of bindings (Rust -> C -> Nim) and it's an extra dependency to build Meros. That said, rustc is already required by other Meros projects, such as Meroxidizer. Given how most users will use prebuilt binarues, either via Docker or natively, this also doesn't change anything for them. Finally, the usage of rustc would also enable access to curve25519-dalek, the premier library for working with Ristretto, which we have an open branch for.

Wry, as a project, also supports Windows 7 and Windows 8 via bundling Microsoft's installer for the needed libraries. Webview has dropped support for these in their latest release. They also currently lack a standing team with the resources and time to develop it, and have numerous outstanding bugs/features. That said, it is older and already in use.

I'm leaning towards migrating to Wry, yet wanted this issue to properly document both sides and my thought process.

kayabaNerve commented 3 years ago

Rust was added as a dependency as part of supporting Ristretto. This aspect is no longer an issue.

kayabaNerve commented 3 years ago

https://github.com/MerosCrypto/Meros/tree/wry moves to it with the notable trade off of allowing multiple instances of symbols when linking. This is a known issue with Rust libs documented @ https://github.com/rust-lang/rust/issues/ 44322 (space added to be polite). That said, the branch is currently non-functional as it's not evaluating the script tag for some reason.

Would probably fix https://github.com/MerosCrypto/Meros/issues/302.

https://github.com/MerosCrypto/Meros/issues/301 would no longer segfault, yet it would still error beyond our control.

(process:1117469): Gtk-WARNING **: 05:46:15.350: Locale not supported by C library.
        Using the fallback 'C' locale.
Unable to init server: Could not connect: Connection refused

(Meros:1117469): Gtk-WARNING **: 05:46:15.352: cannot open display:

This happens when creating the EventLoop, which unfortunately doesn't return a checkable Result. We should probably create a feature request for this.