Quassel IRC

First of all I think this should be user configurable. And I think the question applies only to notices which don't have a channelname as the target.

1.) The most obvious solution would be - as it is now - to determine by the first param (the target of the notice) where to display the message. But as Mentioned this is might not be desirable. (i.e. bots tend to send notices to a user who just joined a channel).

2.) the current buffer. This doesn't need much explanation I guess. Not preferred by me but why not?

3.) the status buffer of the network. In general I do like this option. Seems like a good place to collect the notices. maybe trigger a highlight?

I think notices usually have your own nick as target, and not a buffer. At least that's how it is implemented right now; I did not check the raw message...

Ok, we could make this an option - but for users like me, who'd like to see notices in the current buffer, there is still the problem where to display on backlog replay. Well, then the status buffer is probably ok...

Regarding the backlog issue when displaying NOTICEs on the active channelbuffer (btw: where should it be displayed if your active buffer is a query?):

I'd save it in the backlog of that channelbuffer aswell. When replaying the user should be able to make sense of that NOTICE in the channelbuffer - if not it's not my problem. But this fact should at aleast be noted in the options dialog.

But this leads to a not so trivial implementation issue: how should the core know which buffer is currently beeing displayed by the gui? The core could request the active buffer before emiting the Message::Notice but since it's asychronous I don't feel very comfty with this solution...

As I said earlier: "...but there is no way for the backlog to know this, since this is a GUI thing... one could always transmit a BufferId back to the core and update the backlog, though. Which is not particularly clean."

So that would be the only possibility I see. But the thing is, "current buffer" is not as clearly defined as one might think. In particular, what happens if we have two GUIs connected, and they display different buffers? Which one should determine the "active buffer" and transmit this information to the backlog?

So probably, the best thing would be to store notices in the status buffer of the network. The display-in-active-buffer-thing is mostly a convenience. Usually such notices arrive as reply by a bot (think service bots or quiz/fun bots). It is quite annoying to switch between the channel and the status buffer all the time, especially if it's kind of a dialogue between you and the bot. But on backlog replay I really don't care where the bot's replies are displayed... they're no longer interesting anyway.

There are settings in the client which state where the message should go.

Those settings can be applied on replay aswell, or another set of settings for the backlog can be introduced.

Discussion about this topic is therefore this discussion is irrelevant -> close