feat: Create Pool view#210
Conversation
295c4ef to
35c2dd7
Compare
bf72123 to
2b3ecad
Compare
00e595a to
2594ff2
Compare
2594ff2 to
e8c70fb
Compare
|
Still work in progress, although a lot of progress have been made. Expect things to still be buggy and the code to have architectural smells. For this to properly be implemented and run smoothly may require some changes in LEZ, SPEL and integration with ATA.
Also, I am still maturing the code itself. As the Create Pool view comes with a lot of details itself, the implementation have a lot of code, specifically on protocol.rs. This file is responsible for the business logic, while the API is responsible just to present information in a user-friendly manner. Something I took freedom to explore and implement was the automatic decimals of tokens - as the token program didnt had decimals, at least not in the direct code itself (might be in metadata once we standarize it), I analyzed the common decimals used by tokens overall the crypto world versus their total supply. This works only in QML, it's not part of business logic, and the definition is that the higher the total supply available of a token, the more decimals they have - I found this to be a fair way of demonstrating to the end-user how valuable their balance is, compared to the total supply. Currently the PR include a testnet configuration with a bunch of tokens I deployed in order to test the application, this tokens have several different configurations and name sizes - the configuration only contains the AccountId of the TokenDefinition, the rest is read from LEZ, and statically determined as the normalized PDA pool address. Additionally, would be very useful to have another issue/pr implementing a TokenProgram UI. I plan on extracting part of this implementation (such as chain detection, wallet and transaction) to a separate PR as a library, however we might want to decide that |
38a86de to
ca0b67d
Compare
Add program-neutral wallet access, a stable account model, reusable QML controls, transaction confirmation, submitted-transaction presentation, and isolated contract tests.\n\nRefs #227
Replace AMM-local wallet access, account state, controls, and confirmation-dialog mechanics with the reusable wallet targets. Keep AMM-specific transaction summaries and actions in the AMM UI.\n\nRefs #227
Move wallet lifecycle, account-model synchronization, settings, and reachability behind a composition-based WalletController. Keep AmmUiBackend as the QtRO forwarding adapter while retaining direct WalletProvider ownership for program-specific reads and transaction submission. Adopt the thin-consumer direction demonstrated by PR #230 without coupling the shared module to generated QtRO base classes. Refs #227 Refs #230
Done in https://github.com/logos-blockchain/logos-execution-zone/pull/629/changes Needed to avoid `missing metal toolchain` issue on macOS
The Logos.Wallet QML plugin was installed with an ELF "$ORIGIN" rpath. macOS dyld does not expand "$ORIGIN", so loading the plugin failed with Cannot load library liblogos_wallet_qmlplugin.dylib: Library not loaded: @rpath/liblogos_wallet_qml.dylib even though liblogos_wallet_qml.dylib sits in the same directory. Select the rpath per platform: @loader_path on Apple, $ORIGIN elsewhere, so @rpath/liblogos_wallet_qml.dylib resolves to the sibling library.
Replace prototype data and floating-point quotes with live wallet and chain reads, exact Rust quote planning, and optimistic external-wallet submission. Add canonical display-order mapping, responsive QML states, network-scoped program configuration, and packaged Rust client support.
Implement one create-pool and add-liquidity workflow. Add searchable token resolution, direct opening-price and deposit editing, optimistic pool activation, and base58 transaction IDs. Isolate network, wallet, AMM client, and runtime boundaries. Stabilize quote, submission, refresh, and pool-probe state while consolidating liquidity tests and removing obsolete liquidity paths.
Expose typed Rust request contracts and transport-independent operations for application clients. Keep the existing C ABI as a thin adapter so the AMM UI continues to use the same symbols.
Add responsive step navigation and a wider deposit workspace while preserving the shared create-pool and add-liquidity flow.
Keep token balances and amounts in raw integer units until the decimal display model receives dedicated UX analysis.
Keep wallet assets as token choices without automatically selecting a pair. Keep pool-probe amounts internal so active-pool quotes do not populate the form before user input.
57855e6 to
0605477
Compare
5731c0d to
2538f0c
Compare
2dc502a to
1692581
Compare
This is a Work in progress
Addresses #30