fix: loading state on Send page

[theborakompanioni]

Closes #246.

Infer the loading state based on whether the component is "initializing" or is "waiting" for something.
The distinction has been made in order to separate between "service is enabled, but loading" and "service is disabled, but loading". Before this commit, the loading flag has never been reset if the service was disabled.

Furthermore, with this commit, the behaviour when "waiting for utxos to be reported as spent" is consistent. Service is disabled and loading flag is true.

Service is disabled if one of these conditions is met:

• Maker operation is running
• Taker operation is running
• The component waits for utxos to be reported as spent (new)

[ghost]

Works ✅

Noticed that when "earn" is active, the send page is blurred out while this isn't the case when the scheduler is running. In both cases, the form is disabled so this is really only a UI issue.

[theborakompanioni]

Noticed that when "earn" is active, the send page is blurred out while this isn't the case when the scheduler is running. I

Yes, indeed, that is modeled after the screens in Figma. Just disabled when taker is running, additionally blurred when maker is running. The reason for this is, I think, that the taker operation is started from this screen and the input values could potentially still be displayed (which is currently not the case).

[ghost]

I'd say let's not make this too complex and forward looking and just go with a single style here. What do you think?

[editwentyone]

The reason for this is, I think, that the taker operation is started from this screen and the input values could potentially still be displayed (which is currently not the case).

for send page while collaborative tx active: the idea is the user revisits the send page and sees the values that were chosen, thus its disabled but visible: for this idea to work its needed to see actual values inside the blocked/disabled form

for send page while earn/ jam active: it should show the user, that a complete different process from another page is active thus the complete form is unreadable, the situation is "heavier"

these are details at the end and I think we will concentrate on visual consistency later on, what do you think?

[theborakompanioni]

these are details at the end and I think we will concentrate on visual consistency later on, what do you think?

I have created another PR where the whole form is blurred if a taker or maker operation is running.
As these changes have nothing to do with the blurring, let's discuss this there so this can be merged in the meantime – if that is okay with you.

If the whole form should be blurred, apply the PR, if it is okay the way it is, just close it.

[ghost]

for send page while collaborative tx active: the idea is the user revisits the send page and sees the values that were chosen, thus its disabled but visible: for this idea to work its needed to see actual values inside the blocked/disabled form

for send page while earn/ jam active: it should show the user, that a complete different process from another page is active thus the complete form is unreadable, the situation is "heavier"

Ah I see. Thanks for the explanation -- I can see now where that differentiation can make sense. The thing is that at the moment we don't differentiate between a single collaborative transaction and the scheduler. That means the send page will not be blurred when the scheduler is running (see screenshots). That's why I'd say let's hold off with making that distinction for now and go with a consistent UI until we can actually implement the desired behavior. Does that make sense?