(In reply to Mathieu Bridon from comment #0)
> Polari helpfully displays those messages separately, as if it were a private
> conversation.

Well, they *are* private conversations - it's a bot that initiates them rather than a person, but that's not something we can determine easily. Or gnome-shell for that matter, which actually manages the notification - polari itself just adds the conversation to the room list.

When we implement NickServ support, we can try to do string matches on the message and close the channel in case of success, but unless we did the same in gnome-shell, the notification would still show up temporarily (and that kind of filtering is OK for polari, but not for gnome-shell IMHO).

Another option that would avoid special-casing the NickServ username (and ChanServ actually) would be to have a general "ignore messages from user" option, which would also come in handy anyway I think.

I'm not sure if it's related or if I should file another bug, but right-clicking a private conversation (at least with NickServ/ChanServ) and ending it without viewing the conversation first just results in it re-opening immediately - maybe since it has an unread message?

(In reply to Stephen from comment #2)
> I'm not sure if it's related or if I should file another bug, but
> right-clicking a private conversation (at least with NickServ/ChanServ) and
> ending it without viewing the conversation first just results in it
> re-opening immediately - maybe since it has an unread message?

Yup, see bug 768611.

Actually given that there is the occasional useful message (esp. from NickServ, e.g. "user registration problem), this issue would be better addressed with a more fine-grained filter ("ignore messages from user X in channel/on network Y containing text Z", e.g. "ignore messages from ChanServ on #blah containing "Welcome to").

That said, a straightforward user ignore would still cover a swathe of cases (ChanServ messages are pretty much never useful to me), given that the above is probably a lot more work.

"chanserv" is similar case I suppose ...

With multiple connected networks/joined rooms, this results in 30-60 seconds of sequential shell notifications.

And since they're reply-able, "wave to dismiss" doesn't work - instead it expands each notification to show a reply box.

Any thoughts on the generic "ignore user+channel with text" filter (i.e. if it makes sense as a future feature)?

An interim and more simple step would be a "deprioritise user" setting - i.e. "don't show shell notifications for this user". This wouldn't need to be dependent on message content, since e.g. messages from user-deprioritised ChanServ/Nickserv bots would still be shown in Polari for e.g. registration problems.

(In reply to Stephen from comment #6)
> An interim and more simple step would be a "deprioritise user" setting -
> i.e. "don't show shell notifications for this user". 

Indeed:
https://gitlab-test.gnome.org/fmuellner/chat-notification-settings-extension

Thanks for the pointer to that :) I couldn't find it on EGO though, despite the mention in the README... has it been removed from there?

More generally, though it's appealing as a non-Polari-specific fix, it's problematic delegating this to an extension:

* the overall attitude of the GNOME project to extensions is "totally unsupported" and the first response to shell problems is "disable extensions"(ironically while recommending them as a solution to removed/missing features!);
* there is no stable API;
* extension bugs often take down the entire shell, which with GNOME Wayland means the entire session as well.

Correct me if I'm wrong on any of these, and of course none of this will be news to you :D

Will you consider implementing similar functionality directly in Polari?

(In reply to Stephen from comment #8)
> Thanks for the pointer to that :) I couldn't find it on EGO though, despite
> the mention in the README... has it been removed from there?

No, and I haven't moved it to the official gitlab.gnome.org instance yet either. Right now there's a rule in place[0] that prevent me from using either the hosting site (gitlab.gnome.org) or my e-mail (fmuellner@gnome.org) in the UUID. IMHO that rule is outdated nowadays, so I want to discuss that first before moving it somewhere official.

[0] https://wiki.gnome.org/Projects/GnomeShell/Extensions/UUIDGuidelines


> * the overall attitude of the GNOME project to extensions is "totally
> unsupported" and the first response to shell problems is "disable
> extensions"(ironically while recommending them as a solution to
> removed/missing features!);

That's not really ironic - extensions *are* a powerful way to modify the compositor, but that *also* gives them the power to fuck up the compositor.


> * there is no stable API;

That is true, but sounds worse than it is in practice - there aren't any nilly-willy changes either, so real breakages aren't too frequent. It's just that "stable API" and "access to all internals" doesn't mix, unless you want all shell development to freeze completely.


> * extension bugs often take down the entire shell, which with GNOME Wayland
> means the entire session as well.

Yes, you can think of extensions as live-patching the running compositor. That means it is possible to add functionality and features, but also bugs.

 
> Will you consider implementing similar functionality directly in Polari?

No. Again: Polari doesn't show *any* notification for messages in private conversations. Those are shown by a different Telepathy client, namely gnome-shell. The only way Polari could "implement similar functionality" would be to use some debug interfaces to inject the extension code into gnome-shell at runtime. That's a terrible idea, and I'll point fingers at any app that is caught doing something like that.

> That's not really ironic

I meant it's ironic that they're recommended by GNOME devs at various points when something's changed/removed. It's a "having your cake and eating it too" situation:

"I can no longer do X because of this change": "extensions are a completely acceptable substitute".

"I'm using extension X and GNOME Shell doesn't work properly": "shell extensions aren't supported at all, if you have problems, stop using them".

> It's just that "stable API" and "access to all internals" doesn't mix, unless you want all shell development to freeze completely.

I think that's a much longer discussion, haha.

> Those are shown by a different Telepathy client, namely gnome-shell.

Ah, OK, got it. I had the involvement of the different pieces wrong. So it's a Telepathy (telepathy-haze?) bug + Shell bug really... telepathy-haze to flag ChanServ/NickServ messages in a useful way (low signal/noise messages), and Shell to not notify for them. More or less right?

(In reply to Florian Müllner from comment #9)
> > Will you consider implementing similar functionality directly in Polari?
> 
> No. Again: Polari doesn't show *any* notification for messages in private
> conversations. Those are shown by a different Telepathy client, namely
> gnome-shell. The only way Polari could "implement similar functionality"
> would be to use some debug interfaces to inject the extension code into
> gnome-shell at runtime. That's a terrible idea, and I'll point fingers at
> any app that is caught doing something like that.

IMO this is fundamentally broken. This bug makes it very annoying to use NickServ  with Polari. The solution is to rip out the shell's telepathy client and let apps decide whether to show notifications are not.

We should also remove the feature to allow responding to chats from the notification bubble, because it allows you to lose everything you typed if you click outside the bubble to check something when writing your reply. Very annoying. Automatically solved if Polari creates its own notifications for incoming chats.

The long-term plan is to stop using telepathy in Polari, which would solve this. But it's a plan, polari is a side-project, and time is limited ...

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Polari, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/polari/-/issues/

Thank you for your understanding and your help.