[GTK] Per-surface rather than per-window toasts #5330
Replies: 1 comment 1 reply
-
I would expect notifications to go to the desktop environment. What events did you have in mind? I don't think toasts are the right UX for the bell because a surface on another tab may ring the bell. The GNOME HIG has some guidance how to use toasts: https://developer.gnome.org/hig/patterns/feedback/toasts.html.
I agree that this is not a great idea. I think this discussion is best had with a particular UX which generated a toast in mind. Do you have any? Right now we have:
One UX to think about is if a program reads from your clipboard. Android and iOS (I think) notify users when applications read from their clipboards. At least on Android, the notification is the equivalent of an AdwToast. Does Ghostty currently have a UX for that? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently we place all toasts (aka just the clipboard copy toast) at the bottom center of the screen. This works fine, but when using splits it can be visually confusing as to which split the toast is referring to:

This is not a big issue right now because we only have user-triggered toasts (copying to system clipboard) but this might get very confusing with toasts that originated outside the user's control, e.g. from notifications, events and bell characters, because we don't have any indication as to which surface the toast came from. A user trying to copy text to the clipboard already has the text selected and therefore can visually identify which surface it is, but without that visual aid it's very hard to tell.
For me, probably the easiest and most visually intuitive way to solve this is to have toasts corresponding to each surface be displayed at the bottom center of said surface. That way we don't need any special indication or effect to tell the user which surface the toast belongs to.
An alternative option would be to highlight the border of the split that the toast belongs to. This to me has several downsides, including not being distinctive when toasts are occurring in multiple surfaces (which again, are possible if we do decide to add non-user-driven toasts) unless we uniquely color code each surface and toast, which could potentially greatly confuse the user. It is also visually intrusive and less than ideal accessibility-wise to people who have difficulties differentiating color. However, it would make the position of toasts predictable, which might aid in visual confirmation.
Beta Was this translation helpful? Give feedback.
All reactions