Ok, expanding on Sri's email I think we have two related but separate use cases here:
1) Having an indicator to let us know of running background apps after the window has been closed. 2) Having an indicator that has some level of user interaction, i.e. a messaging app With that said, we have some users ( I fall into this category) who are mostly concerned with #1. I don't like not knowing if Telegram/Discord/Steam are still running after I close them, and I sometimes get surprised that I'm still logged into telegram even after I've closed the window. I rarely interact with the icon itself except to right click -> close. I'm not sure why exactly these apps don't show a running indicator in the Dash for this use case. For apps such as these, closing the window is really just an analog of "minimize", which is as annoying as it is confusing. OSX goes about this by keeping the running app indicator dot on the dock until the app is fully closed to avoid confusion such as this. With this use case, we could probably solve it without the need for a TopIcons solution, and it would solve a huge pain point with my usage. Now the second group actually use the indicator for a functional purpose, and this is the group that would require a TopIcons like solution. These individuals use the notification icons to respond to chats, to play/pause screen recording, and many other usages that I'm not thinking of. This is the use case that I think requires some deep thought about what to do. Does this split between usages make sense to you all? I would personally be entirely satisfied if the dash would continue to show the running apps when after the window has been closed. However, I don't speak for all the users, many of whom expressed dissatisfaction with #2 On Tue, Mar 26, 2019 at 3:17 PM <s...@ramkrishna.me> wrote: > On Tue, 2019-03-26 at 18:06 -0400, Matthias Clasen wrote: > > > > > > On Tue, Mar 26, 2019 at 3:24 PM <s...@ramkrishna.me> wrote: > > > > > > > > > > I am too, but there is more to this. I'm forced to use topicons or > > > some other because when I ask an application to quit, I have found > > > that > > > some applications don't really quit but instead are sitting in the > > > notification area. That's kind of sub-optimal. So even if you > > > like > > > the change we are forced to put topicons back invalidating the > > > design > > > because not everyone is playing fair. > > > > > > > The strategy we went for with the message tray removal was to say: > > If you have applications that insist on using status icons in this > > way, > > use the topicons extension. > > > > You make it sound like using topicions is somehow impure or bad. > > It isn't. > > Yes, that's true. I don't think it's bad or impure, but it isn't as > designed. Obviously we would want to have an experience without having > to use topicons as our end state. > > In the end, we're going to always use topicons unless something > dramatically changes in the status quo. For me, it's mixed messaging. > It's further complicated by the fact that users pick one of many > topicons type extensions and have an issue. It's not a big deal now, > but something worth addressing going forward if it happens that the lag > between desktop release and when it appears on distros continues to > shorten. > > sri > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
