Syrius Improvements

Will be fixed soon.
Left axis could have equal spacing for the top and second value but we can fix that next version.
image

2 Likes

As discussed with @sol_sanctum in Discord.

The ‘My projects’ filter tag, filters on all user addresses, but as a non-pillar owner the result set gets filtert down in the _filterProjectsAccordingToPillarInfo function to all active projects or projects owned by the selected address.

A non-pillar user has to switch the selected address to see its own projects on another address. While a pillar user sees its own projects on all addresses.

For example:
User A has 3 addresses
Address 1 has a pillar registration and 3 projects
Address 2 has 1 project
Address 3 has 1 project

  • When address 1 is selected, the user sees all 5 projects when activating the ‘My projects’ filter tag.
  • When address 2 or 3 is selected, the user only sees project 1 when activating the ‘My projects’ filter tag.

So when address 1 is selected the user is considerd a pillar user, otherwise a non-pillar user.

With the following change the situation would be equal to that of a pillar user and the user would not have to change the selected address to see all his owned projects.

kDefaultAddressList.contains(project.owner.toString())

So far I’ve not been able to detect any side-effects.

this seems like a good improvement.

I forgot about this

Unfortunately, they don’t support native ZNN. We could revisit this when the multi-chain bridge is deployed.

I’ve updated the Mattermost board with most of the remaining tasks from the original post.
Please continue providing feedback so we can add it to the funnel. :slight_smile:

4 Likes

I believe @angelo_a_jr returned most of the ZNN received back to AZ. If you guys are planning on reviving Dework for paying bounties then @SugoiBTC and Angelo might have to submit another proposal on AZ.

I can merge it right away if eveyone is OK with the fix.

I’ll wait for more feedback for this one: Fix fusing address reset #13 .

I’ll need to complete some extra tests on the cicd branch to be sure. Will let you know when they’re ready.

1 Like

Fully tested PR 13 and PR 14 on the cicd branch. Could not find any problems. However, we do need to make a design decission on PR 14. See PR for more info.

2 Likes

The "create phase" will only be visible when the address of the project owner is selected.

I think this is a good approach, as you must know in advance where you’ll receive the funds for your project.

Waiting for more feedback, but I think we’re good. PR #13 is already merged.

3 Likes

I’ve patched a potential problem with getting the chainId from a remote node.

I’ve also added some git info (branchName and git commitHash) for Syrius in order to be easier for users to verify this information directly from Info TabAbout Card.

1 Like

We are approaching v0.0.6 release candidate for Syrius.

Next week the community will be able to test the wallet before submitting the Pull Request to integrate all the changes into the official repository.

3 Likes

Atomic Swaps and Wallet Connect in v0.0.7? Is anything else getting pushed to the next release?

Look forward to testing everything.

1 Like

Thank you! Testing is very important during early stage development and maybe in the future we’ll start integrating an automatic testing framework.

Now let’s focus on delivering v0.0.6 that’s around the corner and has a ton of improvements already and then we’ll start working on v0.0.7.

2 Likes

Are you planning on submitting one big PR or will there be multiple PRs in smaller self-contained chunks?

1 Like

A big PR containing all the changes.

Merged material-3 branch into cicd.

Flutter Material 3 / Material You

Demo Material 3

1 Like

Maybe I missed something but why only one big PR? Why not self-contained PRs of bugfixes and new features to make reviewing and discussion easier? There’s a lot of new code and changes in your branch and I’m worried it will be hard to review if everything is in one PR.

When the branch is fully tested and we’re approaching the release of v0.0.6 we’ll decide on how to submit the pull request(s).

Why not submit separate PRs for features/bugfixes as they get finished? More time to review and discuss before the deadline.
A single PR with thousands of lines of code changes related to different features is hard to effectively review, so I’m not sure I agree with the approach to make large PRs containing a full release.

1 Like

I agree, but let’s see how we can do it efficiently.