Align .error toast color with design prototype

[pwltr]

What happened?

The app's .error toast type uses .redAccent (#E95164), a crimson that doesn't appear anywhere in the prototype; the prototype's failure toasts ("Spending Balance Setup Failed", "Instant Payments Unavailable") all use the .brand orange (#FF4400). Should error toasts switch to the brand color too, or does the design keep a separate red for errors?

prototype:

implementation:

[CypherPoet]

Personally, I think it would be best for the alert coloring to be separate from the brand coloring. Especially when it comes to error messages 😂

[aldertnl]

John prefers to use Bitkit brand color #FF4400, as it is very close to that red accent color, so it's cleaner to just use the brand color (I agree).

[CypherPoet]

John prefers to use Bitkit brand color #FF4400, as it is very close to that red accent color, so it's cleaner to just use the brand color (I agree).

Aye, makes sense.

@pwltr the question now, I think, is how to handle this in the ToastView.

It currently has the following accentColor logic:

    private var accentColor: Color {
        switch toast.type {
        case .success: return .greenAccent
        case .info: return .blueAccent
        case .lightning: return .purpleAccent
        case .warning: return .brandAccent
        case .error: return .redAccent
        }
    }

... so we could either change .error to map to .brandAccent, or change the type that's being passed into the current .error toasts like the "amount exceed" message discussed in #592 to .warning.

The former would be drastically simpler in lieu of a separate color design.

[pwltr]

... so we could either change .error to map to .brandAccent, or change the type that's being passed into the current .error toasts like the "amount exceed" message discussed in #592 to .warning.

The former would be drastically simpler in lieu of a separate color design.

First option sounds good imo. Since there is an effective difference between a warning and error I feel like we should not remove that differentiation from the code, even though they are communicated the same with this change. In case we may want to revert it at some point.

[pwltr]

Android counterpart: synonymdev/bitkit-android#1009