+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

In D21911#482191, @ngraham wrote:

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

I do not think it is such a good idea.
We should better try to use the passive notification by using more components from Kirigami instead of removing them.
Elisa will need to show notification to the user (and much better than now).

In D21911#482195, @mgallien wrote:

In D21911#482191, @ngraham wrote:

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

I do not think it is such a good idea.
We should better try to use the passive notification by using more components from Kirigami instead of removing them.

InlineMessage is also from Kirigami. :)

The PassiveNotification component is unfortunately very easy to abuse because its intended use case is very narrow: it's only for non-critical informational messages. The only time it's acceptable to use them for errors is when the error automatically retries itself, e.g. "network not available, retrying in 5 seconds". For any error message where the user may have to do something to recover, it's not appropriate to use a PassiveNotification. We're trying to remove these from Discover, in fact: https://bugs.kde.org/show_bug.cgi?id=403791

In D21911#482191, @ngraham wrote:

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

There are certainly more improvements possible, but step by step :)

In D21911#482195, @mgallien wrote:

I do not think it is such a good idea.
We should better try to use the passive notification by using more components from Kirigami instead of removing them.
Elisa will need to show notification to the user (and much better than now).

Note that Elisa currently has 4(!) different notifications. There is

• track import notification
• top notification
• passive notification
• Kirigami.InlineMessage

The last two are only used for the media play list. The InlineMessage was already there for the "Undo" action, while the PassiveNotification was used for loading and saving. The PassiveNotification is IMHO not very visible, since it is very greyish and located over the content view.
As all buttons triggering the notification are the ones in the media play list section, I find the new location proposed in this patch quite suitable and IMHO provides a consistent and concise way of presenting the notifications

So, do we find an agreement here?

In D21911#488263, @astippich wrote:

So, do we find an agreement here?

Yes, as said, I miss enough time until at least Sunday and will anyway have reduced bandwidth for two weeks.

I am perfectly okay with the main idea. I agree with the difference between PassiveNotification and InlineMessage .

Please see my comment and other comments

I tried to implement the actions for load and save playlist. However, InlineMessage seems only to be compatible with Kirigami Actions and not with the qqc2 ones, which is unfortunate

That's probably worth a Kirigami bug report.

In D21911#495600, @ngraham wrote:

That's probably worth a Kirigami bug report.

Will do, but I came to the conclusion that we need additional actions for better text, so I added the Kirigami.Action